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ABSTRACT 
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Papers include: (1) "Implementing a Culture of Change: The Five-Year 
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H. Porter); (5) "Architecture and Re-engineering: A Partnership for 
Change at the University of Pennsylvania" (Linda May and others); (6) 
"Successful Planning from the Bottom-Up" (Eric Jacobson and Dolly 
Samson), which examines how strategic computer planning at Weber 
State University (Utah) begins with faculty identifying their needs; 
(7) "The Art and Politics of Re-engineering under Crisis Conditions" 
(Lynn A. DeNoia), which reviews a re-engineering project at Bryant 
College in Rhode Island; and (8) "Doing More with Less: A Pragmatic 
Approach to Getting the Work Done" (Laura M. Hofstetter and Maria E. 
Mullin), which demonstrates how the University of Delaware dealt with 
reduced staffing via information technology. (Some papers contain 
references .) (JDD) 
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Track II 

Leveraging People with Technology 

Coordinator: James R Porter 

Making our people and organizations more effective has always been— and 
continues to be— the ultimate promise of information technology. Expec- 
tations for IT in colleges and universities, where the transfer of information 
is at the heart of the enterprise, are especially high. How can IT help people 
on campus do their jobs better? 
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Implementing a Culture of Change 
The Five Year Transformation of The George Washington University 

by Walter M. Bortz 
Vice President, Administrative & Information Services 
The George Washington University 

Introduction/Lead-in: 

For Centuries, people believed that Aristotle was right when he said that the heavier an 
object, the faster it would fall to earth. Since he was regarded as the greatest thinker of 
all times, he surely could not be wrong - and no one challenged his concept for almost 
2000 years. In 1589 Galileo disproved that theory with his famous experiment at the 
leaning Tower of Pisa - but the power of belief in conventional wisdom was so strong 
that professors denied what they had seen. They continued to say Aristotle was right, 
reinforcing the observation of Niccolo Machiavelli that, 'There is nothing more 
difficult to take in hand, more perilous to conduct, or more uncertain in its success than 
to take the lead in the introduction of a new order of things." 

The George Washington University: 

In 1988, the then 163 year old George Washington University announced the 
appointment of its fourteenth president. With that appointment, the forty-three acre 
campus, but two blocks from the White House, began what can only be called a rebirth, 
as reassessment and reinvention began to occur in every corner of the institution. 
Nothing was sacred -and nothing too small or too large - to escape some focus. Long 
held at bay, the winds of change - driven by ubiquitous information technology - were 
blowing across all facets of our organizational life. 

Leadership For Change 

It should come as no surprise that one of the areas receiving unusual scrutiny would be 
the institution's business practices, especially the processes and procedures emanating 
from its policies. Consider a scenario where major segments of the institution are 
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attempting to make day to day decisions using different data from different sources — 
the results are guaranteed to be less than satisfactory. To put it another way, if a 
university with a budget in excess of six hundred million dollars has units that cannot 
agree on enrollment figures, the number of funded positions, a given semester's 
financial aid commitments, or any other such fundamental information, then all the 
traditional collegial models of problem solving and participatory governance are but 
window dressing. 

While I do not propose that college or university presidents need to understand the finer 
points of TQM or re-engineering methodologies ... I do know that they will not accept 

excuses why something cannot be done. Those of us whose responsibilities include 
information collection and dissemination must meet the challenge of large scale 
transformations which span entire organizations and tax the limits of both our 
technological and human resources. We must be prepared to integrate our information 
systems into those changing organizations, to reengineer processes, absorb new 
technologies, in other words to facilitate the formation of a cohesive institution capable 
of delivering quality, innovation and customer satisfaction. And all of this usually 
means a fundamental change in how we meld computing and communication resources 
to create an integrated enterprise. We must seek synergy of technology and 
organizational process. But merely pursuing technological change is not enough we 
must implement a culture of change if we are to be successful in that transformation. 

Unfortunately, as we are all too painfully aware, change in general is not welcomed by 
most of our colleagues in the Academy. Those with long staff tenure embrace well 
entrenched, standing practices — often with pride of ownership and authorship. It is 
that resistance to change, complicated by unaccommodating or unwieldy infrastructures, 
pressing financial necessity, and the ever present rhythm of the academic calendar that 
so challenge those who advocate and champion change. 

Recognizing the Need for Change 

I do not wish to suggest that prior to the current administration's arrival, former staff 
at The George Washington University had been sitting on their hands, ignoring the 
changing circumstance of technology and related data management. In fact, a student 
information system had been created in-house during the 80's, though by 1988 it had 
limited flexibility in addressing the growing needs of the community. The system was 
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not distributed to users, though reports were readily available. Originally, it had been 
anticipated that an entire information system would be constructed using the student 
system as the backbone. A quick review of a possible timetable for this task - using past 
experience as prologue -suggested a completion date somewhere just shy of the 
University's 200th anniversary in 2021! Had the institution pursued this option, it was 
suggested that we might want to create a profit center, in the form of a museum of 20th 
Century higher education administrative system software. A fitting tribute for so 
heroic an effort. 

As you might imagine, proliferation of systems was rampant during the time the 
University was creating its student system. A mainframe based alumni and development 
software package had been purchased. The financial affairs folks were taking the better 
part of a decade to implement a finance software package. None of these systems 
addressed enrollment management needs, or financial aid packaging and modeling 
requirements, or procurement, or grants and contracts, or a host of other 
administrative systems ... all basic to the successful day-to-day operation of the 
University. Our systems - even payroll - were independent of one another and 
therefore filled with redundant data. They all required regular updates, as well as 
dumps from one to another. Furthermore, this potpourri of challenges was 
compounded by the verification that some costly upgrades to the systems mainframe 
hardware were but twelve months away. To add insult to injury, these upgrades were 
projected to be interim solutions at best - they did not address the issues of integration 
nor improve access to information. It was clear, therefore, as the new administration 
took stock of its environment in 1988-89, that a decision was imminent to redirect the 
University's effort in information management. Our intention was to move as far ahead 
in the utilization of new technology as possible - setting a pace commensurate with the 
rate at which we felt the institution could absorb the change -while implementing 
organizational diagnosis to assess the undedying processes, and the gaps between actual 
and desired work dynamics. 

As with all such major decisions in large and complex organizations, there is some 
distance betv/een the lip and the cup in declaring new policy and obtaining buy-in from 
the community. At the time of the decision, it was apparent that the institution could be 
faced with severe economic contractions as we addressed a host of issues concerning the 
quality of the student body and the faculty. More importantly, even though everyone 
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would have a vested interest in our direction, v^e could not — would not 
accommodate to everyone's individual satisfaction. 

Setting the Stage for Change 

The keystone of our plan was the creation of an "infostructure" designed to support the 
mission and goals of The George Washington University. Our first step: the 
development of a Computing Technology Master Plan. Its purpose: to provide a 
foundation and set the direction for the future of administrative computing, as well as to 
address the issues surrounding academic computing support, especially mainframe 
support. The process that eventually produced the Master Plan was time consuming but 
as participatory as possible. No segment of the community was ignored. It was 
important to have as many "creators" as possible for the new directions that would 
come forth from this document. A quick review of the table of contents of this more 
than 200 page product will attest to its thoroughness. Both voice and data v/ere 
explored in depth, and networking issues along with other telecommunication challenges 
addressed. 

Because of this exercise, it became clear to the campus at large that it would not be 
enough to simply acquire new technology. Our university community was going to 
have to study and learn how the application of technology, in whatever form, could and 
would be used to transform, to reengineer if you will, the various administrative 
delivery systems of the institution. Success in such an undertaking can be benchmarked 
in a variety of ways: the ability to recruit and retain a desired quality of student, 
faculty and staff; a capability to provide the appropriate level of service to these 
constituents; the effectiveness of productivity improvements and their impact on the 
economic performance of the university; and finally - in the grander scheme - whether 
we have furthered the stature of the institution in its accreditations, ratings and 
rankings. 

In order to accomplish these objectives, a clear vision of computing at The George 
Washington University had to be presented, and a commitment to revisiting and 
updating that vision also had to be made. That represents a significant challenge when 
the pieces of administrative machinery - particularly those responsible for computing 
and telecommunications - reside in various vice president's portfolios. Therefore, 
following the recommendations of the Computing Technology Master Plan unveiled in 



early 1990, Telecommunications, the Center for Computing and Information 
Management (including both administrative and academic support elements), and the 
Computer Information and Resource CenterAJser Services (the faculty and student 
support unit), were placed under the direction of one vice president. This 
consolidation, and the recommendations of the study in which the entire community had 
participated, created the foundations and set the stage for significant change. 

Even as we set that stage, it was clear that the University should not exceed the current 
level of resources devoted to administrative computing. In fact, the University clearly 
wanted to rewrite the formulas to direct more of its resources away from 
administrative computing to academic computing. It was under such parameters that we 
began our search for a solution. 

Implementing Change: Creation of an Information Infrastructure 

One of the first orders of business was to make the long range, long term commitment 
to administrative software. In particular, the community needed to decide if the 
institution would "build or buy". Four primary issues drove the decision, all with 
financial import. First: the period of time we estimated it would take to achieve 
consensus on system functionality. Second: a consensus on the current level of IS staff 
proficiency and the training required to bring the resident analysts and programmers up 
to speed. Third: the need to rethink administrative processes and the challenging 
"pride-of-authorship" inherent to that exercise. And fourth: the reality that the last 
two systems the institution had implemented, finance and student, had taken a combined 
effort in excess of fifteen years -- and both were showing signs of instability. 

It was this last issue which drove a strenuous review of our "buy" options, and the 
resultant investigation of available providers of full range administrative systems. We 
desired a "partner", one who would consider bundling a package of services, systems, 
and hardware enhancements in a long term relationship at an attractive and predictable 
cost. To this was added the bottom line requirement that since The George Washington 
University was already spending too much for administrative computing, the annual 
expenditure for this transformation to new technology had to be less than our then 
current budget. 
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A small GW group went to the market and reviewed the status and future directions of 
four higher education software vendors. The institution's ongoing experience and 
senior management's previous experience with Systems & Computer Technology 
Corporation (SCT) of Malvern, Pennsylvania, focused attention on them. 

It was the institution's desire to have a real-time distributed system, coupled with our 
perception of both what SCTs BANNER software was and would become along with 
banner's hardware independence as well as SCT's willingness to contract it's 
instal-ation, modification and implementation to GW's standards. After months of 
contract negotiations, and both rigorous and vigorous internal discussion, a seven year, 
multi-million dollar per year outsourcing contract was signed in May 1991. The 123 
page contract committed the institution to purchase the current version of the 
administrative software, and laid out an aggressive modification and implementation 
schedule. A comprehensive relationship was formed that laid the foundation and made 
possible the institution's transformation to an integrated data, open systems architecture, 
distributed computing technology. In addition, the annual 7 year level payments of the 
contract resulted in an immediate and continuing savings to the University's bottom 
line. Thus we met the challenge of investing, while spending less. 

The implementation of the financial aid module began immediately. On it's heels 
followed the Student Information System, Alumni/Development System and the Human 
Resource System. A decision on the Finance System was postponed for two reasons, 
number one: the newly arrived vice president for finance needed some time to become 
familiar with the landscape; and number two: the financial system software then in use 
had to be "stabilized". A delayed decision also allowed the financial affairs staff to 
carefully review their processes and procedures, and determine appropriate protocol in 
a distributed, rather than a highly centralized environment. 

Redefining the Business Approach Through Technology 

The results of that decision in 1990 and 1991 are obvious in 1993: The George 
Washington University is transforming itself. Perhaps the most significant outcome of 
the change to date is that decisions no longer equate to independent action. Student 
accounts, financial aid, registration, housing and a host of other operations having 
myriad processes are now inextricably linked in an integrated information system 
dependent upon and owned by all. 



No doubt you will not be surprised to learn that the process of transformation has not 
been easy nor trouble free. Large scale organizational transformations of culture, 
resources, and strategy seldom are. Should you visit the campus or otherwise have 
contact with any of the hundreds of staff and faculty who have been involved with the 
activity, you will find various levels of enthusiasm for the software, the manner in 
which the "plan" has been implemented, and the speed with which the process has been 
accomplished. 

What you will find is a community with more information available to them than ever 
before and still in the midst of struggling with the learning curve of new software. You 
will also discover an institution that is actively redefining the way it approaches its 
clients and how it chooses to do business with them. Unfortunately, the fundamental 
synergy of new technologies and processes are sometimes lost on a host of middle 
managers who would rather remind us of the list of yet-to-be-accomplished tasks! 

But I can report to you that the majority of the campus now recognizes that the change 
accomplished, and that which is still underway, is worth the thousands of hours of staff 
time. More and more, users are willing to accede that they - and our clients — are 
enjoying vastly improved service levels and information access. Immediate access to 
information, on both individuals and transactions,, has caused us to rethink how we 
collect the original information used to populate those data bases. An entire user 
subculture has arisen that spends time researching direct data entry. They search for 
methods that allow students, applicants, and prospective employees (as well as a host of 
others) to provide information directly to the system. Students now use touch-tone 
telephones to register. They obtain copies of their class schedule from information 
kiosks located around campus (called "GWiz") and they meet with faculty who can 
advise them on their academic histories with up to the nano-second accuracy. 

At the end of the 1989 fiscal year, seven hundred users were connected to the data 
systems of the University. Last week, we connected our three thousandth user as we 
also announced a major effort to seek a partner for a significant telecommunications 
project, one that we anticipate will permit the institution to take a giant step in 
connectivity, and in the distribution of data, voice and video both on campus and 
throughout the worid as we press the boundaries of the envelope outward to further 
explore interactive long distance learning and the administrative's challenges it presents. 



Summary: A Culture of Change 



I am satisfied that we have successfully influenced our culture within many areas of the 
University. We have done it through the establishment of strong links between the 
enabling technology, organizational processes, and our human resources. Today, every 
campus renovation carries a connectivity budget and includes input from a committee 
charged with technical enhancements. All new construction enjoys representation on 
planning committees from both telecommunications and academic computing support. 
E-mail abounds, software site-licenses are proliferating. The institution is now in the 
enviable position of trying to keep up with an accelerating campus learning curve and 
demand. 

More and more. The George Washington University recognizes technology as an 
integral part of the infrastructure rather than an added benefit of "automation". We are 
beginning to see a return on investment. Fewer letters of complaint from students and 
parents on registration, financial aid processing, or student accounts is a welcome sign 
that the business operations are receding into the background — where they belong! 
There is every reason to believe that future implementations (the Human Resource 
System later this academic year and the Finance System during the next two years), will 
be gentler transitions and provide even more significant benefits to a growing list. In 
the midst of the institution's "coming of age", in an era of enteiprise integration, the 
general population is becoming more computer savvy. Anticipating future directions. 
The University is spending more of its resources to address the convergence of 
communications and computing technologies. High speed networking, off-campus 
network access, on-line library enhancements, networked software depositories and 
expansion of faculty access to additional learning based technologies and training are 
receiving more and more of our attention and resources. New faculty and staff arrive 
on campus each year with more computer sophistication. Computer literacy and 
training will begin to fade as a resource issue as new elements replace them. Bringing 
the entire community along in this enterprise is much like the task that the school 
teacher faces with a classroom of multiple intelligences and abilities. Holding 
everyone's attention and maintaining support campus-wide will continue to challenge us 
into the foreseeable future. 

11 



I look forward to reporting to you again in two years when, if our calendar has not 
failed us, we will be able to share with you additional good news of how we have 
further learned to leverage people with technology. 



EMPOWERING THE USER 
TERRENCE J. GLENN 
VICTOR P. MECHLEY 
CINCINNATI TECHNICAL COLLEGE 
CINCINNATI 
OHIO 



ABSl'RACr 

This presentation describes how Cincinnati Technical College organized 
its efforts to meet the following challenges: 

1. The use of PCs and auton^tated systems was expanding rapidly 
with little or no thought given to integrating the systems. 

2. Users of MIS were demanding more access to the computer- 
based data and faster response on system problems and on 
development of new systems. 

3. The MIS department was being seen more and more as a barrier 
to progress rather than as a facilitator and servicer for progress. 

'I'he CX)ALS of this presentation are to describe: 

1. The PLAN which was prepared to meet the challenges. 

2. The STRATHC^ilPS which were designed to implement the PLAN. 

3. The INNOVATION which was necessary to break away from old 
habits and ways of thinking. 

4. The l-VANC^il-LISM which was invoked to give leadership to the 
PLAN. 
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EMPOWERING THE USER 



INTRODUCnON 

Cincinnati Technical College (CTC) is a two-year, publicly-assisted technical college 
which offers fifty different certificates and associate degrees through four separate academic 
divisions-lJusiness Technologies, I lealth Technologies, Hngineering Technologies, and 
I lumanities and Sciences. Approximately 5,500 students are in attendance at any time 
during the five academic terms, with about 3,100 ITHs. The special emphasis of the College 
is cooperative education for which it has been recognized nationally. Most recently, such 
recognition occurred on the front page of the Wall Street lournal ^ and on the AHC World 
News Tonight With Peter Icnnings .^ 

Like many other two-year colleges, Cincinnati Technical College experienced significant 
bu^ rather steady enrollment increases in the 1980s despite the decreasing number of high 
school graduates. In 1990 a new president was installed, James P. L,ong. Subsequently, 
enrollment jumped 10 percent and 11 percent in the first two years of his administration. 
I lis goal was to lead the College to become a community college. 1 le recognized that 
additional growth was being jeopardized by outdated and outmoded administrative 
computing systems. He directed that a complete review of those systems be accomplished. 
To assist with the review, the College hired a consulting firm. The results of the study and 
the process which was used to plan and implement the new administrative information 
system is described below. 



Ri-:vii :w oi' i-ORCHS a t work 

There were three major forces at work at Cincinnati Technical College in the world of 
information systems in 1991. 

1. I'ixpanding Use of PCs and Non-Integrated Systems 

PCs were becoming ubiquitous. Some were connected to the larger computers in use 
(1I3M 4v361 mainframe for student systems, IBM System/v36 for l^nancial Systems), but 
more and more were in use for stand-alone systems which made little, if any, use of 
data already in computer systems at CTC. Often, in fact, the data being processed 
were data which already existed in the large computers but which had been 
separately entered into the PC. Separate PC-based systems were used to re-enter 
data from computer reports in order to prepare reports required for the Ohio Board of 
Regents. Many analytical reports were also prepared using LOTUS 123 for different 
financial purposes using data which already existed in the System/36 financial 
systems. 

2. Users Demanding More Access to Data and More Integration of the Systems 

'I'he use of second-generation software had provided some basic integration of some 
parts of the student services systems, but there was only very incomplete integration 



Ralph T. King, Jr. "Real 1 lelp: job Retraining Linked Closely to Lmployers Works in 
Cincinnati," Wall Street lourna l 19 March 1993, pp. 1, A9. 
"American Agenda," ABC World News Tonight With Peter lennings , 15 April 1993. 
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with the financial systems. Also, the I'inancial Aid process was manual and 
completely separate from the automated systems. The maintenance of the automated 
systems was extremely difficult because of poor documentation and because of 
relatively high turnover in the MIS department. 

The MIS department was in a Catch-22 situation. When it attempted to resoond to 
the user-demanded changes to the current systems, it often introduced additional 
reporting problems which exacerbated the difficulties and resulted in increased user 
dissatisfaction. The users had seen enough of the level of integration and data access 
which were available with fully-integrated systems to become much more demanding 
in calling for those capabilities at CTC. 

The mainframe in use was being used to full capacity and response time was not 
acceptable at registration for a new term. Since CTC has five terms each year and five 
registration periods each year, the complaints about poor response time had become 
almost a drumbeat. The poor response time from the mainframe systems and the 
poor response from the MIS Department when system changes were required built a 
user perception of an MIS Department which provided poor service overall. 



3. MIS Being Seen More and More as a Bottleneck 

Because of the central role that the MIS department played in the operation and 
maintenance of the automated systems, MIS was blamed more and more for problems 
which affected student service, preparation of accurate reports, and the ability to 
respond to regulatory changes. This third challenge was particularly worrisome 
because the solution to the first two challenges clearly depended on effective 
leadership and teamwork from the MIS department. The longer MIS was seen as 
"part of the problem" the more difficult it would be for MIS to be seen as "part of the 
solution." 

Over time, the user community came to accept the MIS department's poor 
performance as a fact. There was at least one benefit to the users from this fact. 
Whether it was true or not, it was relatively simple to blame the MIS system for any 
and all problems which occurred. This finger-pointing was a convenient cover for 
other problems and became a part of the culture. I-veryone knew that the MIS 
systems were unreliable and set their expectations and attitudes to reflect that 
knowledge. The MIS personnel reali/.cd that they were being blamed for problems 
which pre-dated their employment at C TC and that their role was not regarded as 
valuable and supportive. This realization contributed to the morale problems within 
the department and an adversarial relationship with the users, lioth of these factors 
contributed to a high rate of turnover in the MIS department. 



PLAN TO ADDRl'lSS TI II': Tl IRl-l-: CI lALlTlNGl'S 

CTC decided to attack all three challenges at once with a team approach. The design of 
this team approach was based on the work done at Sinclair Community College-'^ and at 



118 



Georgia Tech^. The team would include both the users and the MIS personnel with the 
users providing the overall leadership to the effort and having the final responsibility for 
the major decisions. It would include both management and workers, from the user 
departments and from MIS, with input regularly gathered from all. It would include both 
the academic and the administrative areas because it was clearly seen that a key part of 
integrating the automated systems was integrating the ability to access the functions and 
data those integrated systems would provide. This integration had to cross all lines of the 
organization through the use of systems for which all parts of the organization felt 
responsibility. 

A task force was formed which included representatives from all departments, all areas, 
and all levels of the organization. This Task Force was asked to be a sounding board and a 
generator of ideas for the overall project. It continued to meet periodically throughout the 
planning and the implementation stages of the project. 



An approach to project management was designed which would use the organizational 
structure which was already in existence to populate three levels of project effort. 

Top Level - Executive Systems Review Board (I'iSRB) 

The Executive Systems Review Board (FiSRB) included the academic deans; the vice 
presidents for student services, finance, and administrative services; the dean of admissions 
and counseling; and the director of human resources; with the director of MIS as an ex-officio 
member. An organizational chart appears below in Mgure 1. 
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Rguro 1: Organisational C^hart for tho Update "93 Project 

The liSRB was charged with the responsibility for setting overall policy for the project 
and for making the major decisions concerning computer software, hardware, and personnel 
assignments. It guided the development of a Request l*or Proposal (RI'P) and led the 
selection process to evaluate and choose software and hardware vendors. The process 
included in-depth interviews with all members of the Task I-orce concerning their areas' 
current systems, system problems, and needs for the future. These interviews resulted in 
written statements of needs which were consolidated into the RI*P. 



Linda Martinson, "Scrapping Patched Computing Systems: Integrated Data Processing 
for Information Management, " NACUBO 13usiness Officer . June 1991, p. 35. 
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The project to upgrade the Administrative MIS to meet the requirements stated in the 
Rl-P was named UPDA TI: '93. 'I'he acronym stands for User Planned Data Access Toward 
Hmpowerment. The name intended to identify not only the process of upgrading the 
systems but also the teamwork approach being used, 

The specific goals which were set for the UPDA TP. V3 project were the following. 

1. Use of a relational database management system to support data integration, easy 
access, and powerful reporting tools. 

2. I'he ability to communicate from any PC or terminal in the College to any other PC or 
terminal in the College, 

3. The ability to download selected data from the central database to department PCs for 
further analysis. 

4. Vast access to the data to improve service to the students in all interactions with the 
College, 

5. 'I'he ability to add new features and functions (I';-Mail, telephone registration, 
IN ri-RNF/r access, etc.) without major changes to the basic system. 

6. The ability to greatly expand the number of students served without a major expense 
to upgrade the hardware or software. 

To advise him on the contents of the RPP and the criteria for the selection of the new 
system software and hardware, the president recruited a Blue Ribbon Committee of data 
processing executives from the business community. These vice presidents of major 
insurance, banking, and information systems firms met with the president and 
representatives of the HSRI3 to provide feedback, direction, and confirmation of the approach 
used. When the president took the recommendation for the purchase of a major new system 
to the Board of Trustees, he had not only the selection of the internal committee but also the 
concurrence of an independent outside panel with many years of experience in purchasing 
and designing software solutions. 



Second Level - Implementation Committee 

C^nce the selection of software and hardware had been made, an operating committee 
was established. It was called the Implementation Committee. It had the responsibility for 
making the decisions necessary to make the project happen. Those key executives in whose 
areas the new system would be installed were included, namely the registrar, controller, and 
the dean of admissions and counseling. In order to maintain a balance of academic and 
administrative viewpoints, the dean of health technologies, the senior academic dean at 
CrC, was also included. The director of MIS was made an ex-officio member. The selection 
of these members was made purposely to include two members of the PSRI3 in order to 
provide clear communication paths horizontally as well as vertically within the organization. 

The Implementation Committee decided to set up sub-committees which would be 
populated with members of the Task I'orce and MIS department people. 
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Third Level - Sub-Committees 

I'our sub-committees were formed initially. The subcommittees were composed of 
midlevcl managers and staff who would be ultimately responsible for working with the new 
system on a day-to-day basis. The subcommittees provided leadership opportunities and 
decision-making authority to persons who were not used to having these roles within the 
organization. 

1. DATA MANAC^I^Ml^N r AND SliCURITY - to plan what data needed to be converted 
and what security needed to be applied to the system. 

2. TRAININCj - to plan and guide the training required. 

3. CC^NVMRSION - to develop and recommend the conversion sequence to be followed. 

4. ANCILLARY APPLICA TIONS - to make sure that any current needs for automated 
systems which were not included in the packaged software werj addressed during 
the life of the project. 

The four subcommittees met regularly for several months. Through their input, they laid 
the foundation for the implementation of the new system. I'he subcommittees crossed 
departmental lines and initiated the team building efforts. Subsequently, when the 
conversion became the primary focus, the Data Management and Security, the Training, and 
the Conversion subcommittees were combined into a single group called the Planning- 
Training-Problem Identification (PTP) subcommittee. PTP included all of the key supervisors 
from the user departments and all of their MIS teammates. 

nl:w stratl:c;il;s dhvhlopld 

1-rom the experiences gained by site visits during the selection process, the project 
leadership realized that the implementation phase would provide the greatest test of the 
teamwork approach. In order to help assure success, several strategies were developed. 

1. Users who have PCs but do not understand them well must be made more computer- 
literate . Training classes on PC i^'undamentals and DOS were developed and 
implemented using a "train the trainer" approach in order to institutionalize the 
knowledge. The training was conducted by a team made up of user personnel and 
MIS personnel. It included representatives from the academic areas as well as the 
administrative areas. A new L-Mail system was selected and installed on the new 
administrative network to help solidify the knowledge which was gained in the PC 
training. 

2 Users must be provided better access to data through an integrated software system . 
This system is built on a Relational Database Management System (RDBMS) in order 
to provide the tools needed to effectively manage the database and to support ad hoc 
access (QUF.RY) to the database. To build on the training done earlier, the software 
vendor was brought in to CLC to conduct focused on-site training on the software 
modules. This system software module training involved both user and MIS 
personnel and was accomplished again using the "train the trainer" approach. Doing 
the training on-site allowed a much more focused effort. All questions and concerns 
were CTC's questions and concerns. All examples and solutions were 
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CrC examples and solutions. Training on the QURRY capability was provided to key 
personnel in all departments, not just to MIS personnel. User personnel were 
involved in helping to deliver the QUERY training to other units. 

CrC recognized that empowerment of the users depended on three separate 
ingredients, computer literacy, integrated systems, and the Query capability. (Sec 
Figure 2.) Each of these ingredients needed to be acquired over a period of time, in 
an integrated manner. 

TOTAL EMPOWERMENT 



Query 



Integration 




Literacy 



Figure 2: Compulor Liloracy t Inlogralod Systems < Quory Total Hmpowermont 

MIS personnel must be reoriented to a user-service point of view. This change of 
attitude was accomplished through the identification and development of leadership 
within the MIS personnel, through the team-building previously described, and 
through assigning MIS personnel to specific teams with user personnel. User 
managers were regularly asked for input concerning how well the MIS personnel 
were supporting the efforts of the team. Problems which were identified were 
addressed immediately. In addition, MIS personnel were regularly asked for input 
concerning the cooperation being shown by the user personnel. Problems identified 
with those relationships were also immediately addressed. 

The modus operandi for addressing teamwork problems, from whatever source, was 
to meet with the personnel involved to review the problem and to develop a solution 
to which all parties agreed. If necessary, the next higher level of management was 
involved in the discussion in order to reach a consensus on the problem definition 
and on a solution. Since all of the departments involved in the project already had 
key executives on the different teams, it was relatively simple to gather the necessary 
personnel together and focus their attention on a common definition of the problem. 
In a few cases, it was necessary to raise the problem to the level of the I'iSRB in order 
to achieve the necessary level of cooperation. With all parties generally 
knowledgeable concerning the overall project, it was not necessary to prove problems 
existed so much as it was necessary simply to identify the problem and to show how 
it was interfering with effective progress. In addition, it was stated as policy that 
UPDATli '93 was to be user-driven with all major decisions made by the users. 



INNOVATIONS lMPLHMI{N'Il-:i) IN IDl-lAS AND IN ACTIONS 



The project leadership introduced a number of innovative ideas within the 
implementation phase, l-irst, teamwork was stressed as essential, not just a good idea. 
Ck)od teamwork was recognized and rewarded with special recognition during meetings. 
Poor teamwork was also recognized, and appropriate corrective actions were taken. The 
previous adversarial relationships and attitudes were weeded out through joint successes 
and through recognition of the essential need for the full participation of all those involved. 
Second, decisions were not allowed to be made by single individuals, whether the 
individuals were department managers or vice presidents. All decisions had to be joint 
(integrated) decisions in order to successfully implement the new integrated system. I'hird, 
MIS personnel were not separate from the team effort. They were expected to be team 
contributors, not remote gurus or gofers to be ordered about. I'ourth, the new system was 
not an end in itself, but the first stage of a process which would be continuously reviewed 
and improved. The Total Quality Management'' approach, with the general recognition for 
effectiveness it has received in industry, was most helpful in this effort to convince the staff 
that change is part of the new way of operating. 

In addition U> the innovative ideas, a number of new actions were introduced. I'irst, 
team assignments were announced publicly, and team performance was recognized publicly. 
Second, inter-department training was made standard. The Admissions personnel, once 
they had learned their module, were expected to train other departments on how that 
module worked. This approach solidified iheir understanding of their module's functions 
and contributed to team.work and improved communications. Third, quick identification of 
problems becam.e the order of the day. Anyone who did not identify problems of which 
they were aware became "part of the problem." I'ourth, recognition and celebration of good 
performance and of successes became a regular part of the weekly meetings of the different 
working groups. 



UVANCliiUSM 

To break through the barriers which the culture at C TC presented, the project leadership 
continually stressed the inadequacies of the current situation, the benefits of the new system, 
and the essential need to implement the new system in order to prepare CTC for the future. 

This evangelism took several forms, l-irst, the Board of Trustees and the president 
confirmed the goals to be achieved with the new system. This confirmation was invoked to 
help add force and credibility to the need to assign all necessary resources to complete the 
tasks. Second, management stressed the total inadequacy of the current system and the 
essential need for change. 'Third, MIS personnel continually sold the excellent benefits to be 
achieved through the empowerment of the users. T'ourth, several boosters of the new 
system were identified and encouraged to speak out positively among their peers and their 
staff about the benefits of the system, the importance of moving forward, and the need to 
meet project deadlines. 



W. I'dwards Demming, C Xit of the Crisis . Massachusetts Institute of 'Technology, 
Center for Advanced Engineering Study, Cambridge, Massachusets 1986, p. 4. 
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Rl'iSULTS ACHI1-:VHD 

As a result of the successful implementation of these plans and strategies, these positive 
results have been achieved. 

1. The computer-literacy of the organization has been upgraded. 

2. The users and the MIS personnel have a deeper understanding of the essential value 
which each group brings to the work. 

3. The automated systems are fully integrated and provide a solid basis on which to 
improve service to the students and to upgrade overall efficiency. 

4. The installed network enables all employees to access the data they need to fulfill 
their assigned responsibilities. 

5. Communication between and among all employees is faster, more actionable, more 
accurate and less-paper dependent than before as a result of the use of li-Mail. 

6. The future developments in computer systems are now options which are available to 
CTC. There are no artificial barriers in the way to the use of telephone registration, 
access to INTI-RNIiT, electronic exchange of data files, or other new developments. 

7. Users have access to the data on the central system and can download a copy of 
selected data to their PC for further analysis. 

The system configuration has been altered dramatically. I'igure 3 is a visual 
representation of the automated systems before the conversion. 




I'iguro 3: CYC Information Sysl(^ms Hoforo Updalo '93 
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The new Information Network eliminates the hardware variety and network complexity 
which existed in 1991 and provides simple, direct access to all network services. (Sec Mgurc 
4.) In summary, the new CTC Information Network provides a solid basis for future growth 
in the use of the database and in communication across the network. Users are now truly 
empowered. 



CTC Network In 1994 



Qicnts 



Administrative 



Academic I-thcrnct 



PCs 



Terminals 



Printers 



Bridge 



i-thcrnet 



Servers 
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Syslem Servc?r 



H-Mail, Htc. 



I'igurc 4. CTC Information Systems After Update '93. 
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User-Driven Training - A Strategy for support 

Ken Pecka 
Whitworth College 
Spokane 
Washington 



Abstract 

Investment in information technology on the campuses of small colleges 
and universities has been a high priority in recent years. One important 
area which seems to got less attention, in this rush to attain technologic' 
adequacy is the investment in the training and support of our human 
resources. 

At Whitworth College we are implementing a training program basod on a 
strategy for training and support that places the focus of attention on 
user-identified needs. It is a strategy that identifies the users as the 
central figures in identifying, defining, and organizing their own training 
and support needs. 
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Introduction 



As Wliitworth College embarked on a major 
computer system upgrade which inchided 
administrative hardware and software, networking 
and facilities enhancement, it was clear that the 
nser support services would need to be enhanced. 
Historically, investment in hardware and software, 
although not excessive or easily attained, far 
outweighed our investment in the personnel who 
would be required to use the equipment and 
software. 



Traming tttid Support,. 

What Us^rs Need 
When They Need It 
Where They Want It 



As we considered the significant investment that was being made, it was clear that 
unless commitment was made to training and support, we risked jeopardizing the 
effective use of upgrades and enhancements. Worse yet, we jeopardized the potential 
benefits of the new systems. 

This program is a response to these concerns. It is based on the desire to gain the most 
from our investments, and to establish an environment of professional developnieui 
among our employees with regard to the use of technology. 



STATEMENT OF PURPOSE 



The training in technology program was designed to establish and nurture an ongoing 
atmosphere of training and stipport for computer technology on the Wliitwortli (lollegc^ 
campus that meets the growing needs of the faculty, staff, and administration of the 
C.-ollege. This ''atmosphere of training and sup])ort" relies on the end user as the 
central point of focus. The program has created a USER-DRIVEN training and 
support environment that encourages end users to be involved in directing their own 
professional devek)pnient. Users play a major role in setting the schedules, identifying 
topics, establishing training groups, and the identification of training and support needs. 
The underlying strategy supporting the defined program is dependent upon the 
continued input from the participating employees. 

By asking employees to analyze their own training needs, to consider those who they 
might be trained with, and to request the stylo of training they prefer, the rc^sulting 
training sessions can be both meaningful to the employee and beneficial to the 
institution. To accomplish this task, a variety of methods and training approaclu^s are 
re(iuired. This program has formalized these ideas which are critical to the success of 
any training effort implemented at Whitworth. 
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PROGRAM OBJECTIVES 



1. 



Enhance, encourage, and direct tlie appropriate use of the College's tc^chnological 
resources through the training and support of our human resources 



2. 



Enhance the skills, knowledge, and technological understanding of campus 
technology users, enabling them to better accomplish institutional objectives 



3. 



Establish a user-directed system of support and training that provides job related 
professional development opportunities for the employees 



Training Styles 



► 



Classroom Training 
Workshop Training 



Workplace Training 
Individualized / Self-P aced Training 



Classroom Training 

Classroom training involves the use of formal trainhig sessions which are hold in a 
classroom or lab with both lecture and hands-on training. This traditional format is 
useful in supplying training for general needs and foundational knov/ledge. Introductory 
courses in a variety of topics are well served by this approach. 

(Classroom training sessions are targeted as one-hour training sessions witli 40 to 45 
minutes maximum for actual instruction and the remaining time reserved for (luestions, 
comments, and discussion. 

Workplace Training 

Workplace training provides training that is specific to a particular "workplace'. The 
needs of one department are sometimes unique in specific areas of a given aj)plication. 
This type of training takes place in the departments at the actual workplaco of the 
employee(s) receiving the training. By conducting the training in the departments, 
focus and attention can be given to the specific needs of those being trained. For many 
employees, this style of training best meets their needs. However, care must be given to 
protect the training time from potential interruptions common to the workplace. 

Workplace training session time schedules are held to one-hour when appropriate. Tho 
end-users help to establish the time that ;s allotted for each specific session. 

Workshop Training 

Workshop training consists of a concentrated series of training sessions to covi^r a topic 
in greater depth. Sessions vary in duration and number of meetings depending on the 
topic. This type of training may take place outside of normal office hours utilizing 
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ovoiiings and/or weekends. TTser input is welcomed in helping to identify topics, time 
schedules, and possible incentive programs and options. 

Workshop trainhig sessions may include the use of off-campus personnel and 
organizations to provide the training. Issues of cost and associated fees necessary to 
bring in outside services are assessed for each identified need. User input is critical in 
making this type of training effectiv^ 

Individualized/Self-Paced Training 

Individualized training allows for employees to receive training either on an individual 
basis or as self-paced training. Materials used in providing this form of training hicludo 
internally developed tutorial workbooks, published workbooks, and audio and video 
training tapes. 

The development and/or purchase of the training materials necessary to support this 
form of training is important to the success of this style of training. The materials must 
ho thorough and generally available for access by employees. 

Although the bulk of this training is self-paced or independent study, sonic 
hulividualized one-on-one training is required. A variety of personnel are involved in 
providing individualized support for other employees, including peer-to-peor training 
sessions. Much of this type of training is informal and occurs "naturally" within the 
daily activities of the job. Use of peW-to-peer training helps to support the growing 
noods in this area. As personnel are trained in areas of need, they are very willing to 
share this knowledge with others. In this process, employees learn more about both 
tochnology and about each other and the jobs they perform. 

TRAINING GROUPS 

► General Training Groups ► Departmental Training Groups 

► Positional Training Groups * ► Specialized Training Groups 

General Training Groups 

This group includes any employee of the College interested in the training being offered. 
Topics offered to this group are general in nature and provide an introduction to 
software packages and applications. General training groups are limited in size only ])y 
the facility limitations or by the instructor's request. 

Departmental Training Groups 

This group includes employees who work in the same department. Use of this group 
configuration allows for meaningful dialogue and discussion during the individual 
training sessions. It provides a natural environment for departmental cross-training as 
employees participate in training together. Questions asked during a given training 
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sossioii are of greater interest to the group. The topics covered with this group type 
vary and include intermediate and advanced application training. Departments may 
decide to develop multiple training groups within the department to achieve the most 
effective training possible. 

Positional Training Groups 

Tliese groups consist of employees of like appointment and position within the College 
with similar responsibilities and needs. In most cases they do not work in the same 
department or even in the same division of the College. Groups of support staff 
employees, faculty members, administrators, department managers, and professional 
and technical employees are some examples. Training topics for this group are 
relatively specific to the job performed. Topics are determined by the needs of the 
grotip. 

Specialized Training Groups 

This group may consist of a variety of campus employees and are formed as a result of 
an identified special need. These needs may include topics such as use of specific 
hardware and/or software. Topics covered may become fairly advanced in nature and 
may bo very specific to a givon discipline or department, or simply of interest and need 
to a specific group of individuals. 



Introductory and Fotindational Topics 

T()i)ics covered under this category include introductory training for a variety of 
software packages and technological awareness. These topics cover the basic operations 
of a g'.'on package and provide the user with the skills necessary to operate the software 
at an elementary level. Other non-application specific topics include file management 
and (lata organization, basic hardware maintenance and problem resolution, printer 
opfTations, and others. 

User Job-Related Topics 

As discussed previously, the end xisers play a major role in directing the training and 
support services offered. A significant component of the user's role is in providing 
feedback and suggesting topics for training sessions. In identifying training topics, users 
are encouraged to provide suggestions based on their job-related needs. Specific 
functions from a variety of aj)plications may be necessary. No topic is considered to be 
i.oo minor, too specific, or too elementary. 
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Introductory and Foundational Topics 
Features and Functions Topics 



User Job-Related Topics 
Brown-Bag Lunch Topics 
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This approach to topic selection is designed to accomplish at lestst three significant 
objectives; 1) Users will be participating in training that addresses their specific needs, 
2) users will become more conscious of their training needs and the definition of those 
needs, and 3) users will be more likely to experiment and try new functions if they 
know thoy can request training. 

Features and Functions Topics 

Topics from this category include specific functions of various software packages that 
are beyond the introductory level of operation. These topics are offered on an as 
requested basis and are open to general, departmental, and positional training groups. 
Some topics require a sequence of sessions in order to achieve the training objectives. 
Employees are encouraged to participate in appropriate levels of training based on their 
experience, expertise, and needs. 

Features and functions topics are offered in classroom, workplace, and v/orkshop styles 
of training. The specific style is dependent upon the specific topic (s) to be covered, and 
the desires of the group and the instructor. 

Brown~Bag Lunch Topics 

On a regularly scheduled basis, "brown-bag" lunch sessions are held to discuss .a variety 
of technologically related topics. Topics to be discussed are determined tlircagh user 
input and suggestions eus well as topics selected by training staff. ComputcM' services 
staff members coordinate the lunches and provide hiput (along with attending users) 
into the topic of choice. Topics range from specific problems with hardware and/or 
softwivre to issues of policy. 

Lunch sessions provide ideas for formal training sessions that are developed and 
scheduled for training* These sessions provide a consistent resource of meaningful 
training topics and serve as a mechanism for end user feed back, comments and 
suggestions. 

TRAINING FACILITIES 

► Training Center Computer Labs 

► Campus Classrooms &; Conference Rooms Office Work Areas 

Training Center 

The training center is located in the computer services area of the library. The facility 
is utilized for a variety of training sessions and is equipped with 6 networked computers. 
Formal training sessions with a maximum of 12 participants may be conducted in the 
center. In addition to formal training sessions, the training center is used for 
individualized or self-paced training. Users may schedule the training center for a 
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vari(?ty of training sessions. Scheduling of the contor is managed by the User Support 
Specialist. 

Computer Labs 

Both the Macintosh and the PC coini)nter labs h)cated in the library are available for 
training sessions. Due to tlu^ heavy use of the labs by students and for classes, 
scheduling is coordinated with academir computing. Training of larger groups (1.0 or 
more) may be conducted in the labs when appropriate. The labs can be us(hI for a 
variety of training topics and styles and offer an ideal environment for training that 
requires hands-on access. 

Campus Classrooms ic Conference Rooms 

In certain cases, training does not require hands-on exi)erience. At such times, training 
may take place in lecture classrooms and/or conference rooms throughout the campus. 

Office Work Areas 

In addition to the use of the formal training facilities, the use of office work nreas is also 
l)eneficial. Depending upon tlu^ style of training taking plac<\ it is oft<Mi useful to utilize* 
th(* spcH'.ific work area of the individual or group r(M'eiviug the training. Tins lias j)rov(Mi 
to be especially useful in the training of (Mnployc^vs in the use of network ])rinters located 
iu th(*ir individual buildings. 



User Support Specialist 

Tlie Us(*r Support Specialist position supports the ongoing user training and su|>port 
('fforts of the ('olleg(\ It is clear that the potential benefit of the new technologies being 
iuiplement(Ml thro\ighout tin* (College ran only b(* r(\'U'.li(*d if W(* i)rovide ongoing training 
and support for the end-users. 

The User Supi>ort Specialist is responsil)l(* for the coordination of user sui)port s(M'vices 
and training ]>rograms. This includes tlu^ scluMluling of training sessions, conducting 
ihmmIs ass(\ssnient surveys, devc^lopment and i>urrliase of training materials, nnd 
conducting training sessions. 

Although cond\icting training sessions is a significant part of this i)ositioirs 
responsil)iliti(*s, a wide variety of training rc^sourre j>ers(>nn(*l arc* nec(\ssnry to provide 
th(* d(\sired 1(*V(»1 of support. The UstM' Sui)i)ort Sp(*cialist coordinat.es the use of facility 
an<l staff instructors to me(*t the training netvls of the cani|)us. 
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Computer Services Personnel 
Applications Specialists 
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Computer Services Personnel 

The members of the computer services organization of the College participate in 
conductmg training sessions in a variety of software and hardware applications. The 
expertise of the department members is used to provide training and support to the 
campus users. 

Department Personnel 

There are a number of employees who have the expertise, skills, and ability to teach a 
variety of topics. We encourage these individuals to participate in the training program 
as instructors or tutors. Some train others in their departments, while some become 
involved in campus-wide training sessions. It is certain that the success of the training 
and support program relies on the expertise of experienced employees who are willing to 
share heavily in the training of others. 

This program provides the opportunity for employees to support the efforts of their 
fellow department members and co-workers campus wide. These opportunities provide 
unique experiences for employ<jes outside of their normal work responsibilities and 
duties, enhancing their understanding of the needs and responsibilities of others. A 
resource survey form is used to identify employees interested in training others. 

Application Specialists 

In certain situations, it may be beneficial to enlist the services of a software application 
specialist to conduct training sessions on campus. A number of organizations, vendors, 
and consultants offer this type of on-site training in a variety of applications. 



TRAINING MATERIALS LIBRARY 

We arc in the process of establishing a training and support library that will Uo 
available to the employees. When completed, this library will include a variety of self- 
paced and individualized training materials. Users will be able to use the materials on 
campus and at home for the purpose of software training. 

Training materials will be available in the training center and through the Audio Visual 
(h^partmcnt. These materials will include video training tapes, audio training tapes, 
reference manuals, self-paced work books, quick reference guides, and other resources. 



PROCEDURES FOR REQUESTING TRAINING 

Application of the USER-DRIVEN training and support environment relies ii(\'ivily 
tipon input from the end users. This input is collected in a variety of ways, Use of user 
surveys, questionnaires, training request forms, and open comments and suggestions arc 
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vital to the success of the program. All information and requests are processed by the 
User Support Specialist who directs the implementation of the requested traming. 

The users are asked to complete a Training Request Form that details the desired 
training topic, the preferred training style, a suggested time schedule and date, and the 
training group that will participate in the training. In addition, the requestor s 
supervisor is asked to approve or validate the user's request before it is submitted. 
Each training topic is submitted on an individual request form. Users are encouraged 
to submit as many requests as are necessary to meet their training needs. The only 
limits are those created by scheduling conflicts and the time allotted within departments 
for training. 

The purpose for gaining a supervisor s approval is to ensure that the training being 
conducted is appropriate for the specific job responsibilities of the employee making the 
request. Our intent is to provide the necessary training and support to mv^^l the 
institutional needs of our users. 

Once a user has completed a Training Request Form, it is submitted to the User 
Support Specialist for scheduling. Verification of the scheduled time and date of the 
training are sent to the requesting party and members of the specified training group (if 
applicable). In some cases, announcement of the scheduled training is ma<l<» to the 
general campus. 

Every effort is made to meet all of the approved training requests, Schedulhig conflirts 
do arise and are resolved base<l on our desire and ability to maximize our training 
(efforts. 

Program evaluation and Revision 

Every training session is evaluated by the users. They are asked to provide input on 
the usefulness of the information covered and to provide suggestions for further study 
and training. This evaluation is intended to provide iunnediate feedback to the 
instructor and direction for future training. The evaluation form is quite simple and 
requires very little time to complete. 

In addition to the written evaluation, conversations with participating employees as to 
the value of the training programs offered has proven to be very beneficial. Taking the 
time to talk with the users regarding their training needs and experiences is time well 
spent. These conversations can take place over lunch, in passing conversations, or 
through electronic communications. 
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Theory Into practice 



Planning and design for this program began in February, 1993. Due to fiscal timing, 
the User Support Specialist w?is not hired until August, 1993. Formal implementation 
of the program was initiated at the beginning of the Fall 1993 term. 

Presentations of the training strategy and program operation were made to three major 
personnel groups on campus; support stafT, professional staff, and the faculty. 
Introduction of the User Support Specialist and the proposed operational procedures 
were made during these presentations. The concept of the program was well received 
by the entire campus and some began making their requests immediately. 

However, we soon realized that some of onr assumptions were a bit optimistic. A 
number of employees had difficulty defining their training needs, particularly when 
attempting to identify specific needs. They recognized their need for training but found 
it difficult to accurately define those needs. There are probably several reasons for this 
but two seemed to be quite clear. 

First, many users simply were unable to identify specific training needs related to 
sp(H-ific software. They recognized the need for training in a given area, but W(U-e 
uncomfortable witli the terminology. Therefore, they were not sure how to define their 
re<iuests. As a result, we began to encourage users to define their needs in terms of 
what they did at tlieir job. We encouraged them to (h'scribe their needs in non- 
technical t<Tms by simply dtvscribing tlieir daily tasks. Then we would work with tlieui 
to nnU.cli the activities of the job with approi)riate training in specific software 
pa.ckages. Using this approach, users can more easily define "what they d(>'\ and gvi 
support in defining how technology can play a role in supporting their needs. 

A second reason seems to be more historical in nattu'e. With a history of not providing 
a.deciuate training for our users, it is taking tluun some time to get accustomed to the 
idea that they can request training as needed. The idea of taking an activ(^ role in the 
directing of their own training rec^uired some adjustment. We continue to (Mlncate our 
us(U's as to the purpose and operation of the ])r()grani emphasizing the important roh^ 
they play in the success of this program. 

As is the case with most strat(^gies and/or theories, tln^y are nnich easicT to (hn'elop 
than they arc* to implement. We continue to h^arn from the im])lenientati()n procc^ss and 
ns(^ this oxj)erience and knowhnlge to review and modify the program. As vv(^ r<wi(nv 
and revis(* our program, the strategy of a "tiser-driven'' training and sui)p()rt 
environment has been maintained. The users rtMuain at the center of the })rogram and 
contiiuie to gtiid(* otir efforts of training in technology. 
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The End-user's Desktop: 
New Center of the Computing Universe 

Presented at CAUSE93 by James Porter 



I. Introduction 

Our current approach to end-user support is directed at achieving computer literacy. For the most 
part we provide our administrators, faculty and students with classroom training in the use of 
desktop applications running on their personal computer (PC). Little effort is expended on 
assisting the end-user integrate the PC, the network and the task at hand, whether that be managing 
a department, recording student grades or researching and writing a paper. As a result, many — and 
some would argue most — of our PCs are serving as typewriter replacements. 

Needless to say, with our PCs serving as typewriter replacements, little of the reduced costs and 
increased organizational effectiveness expected by many from desktop computing is being realized. 
Indeed, it could be argued that since we tolerate non-use and our organizations incur the cost of 
duplicate administrative and communication systems, PCs have contributed to increasing costs 
rather than reducing costs. For example, we do not require all faculty, staff and students to use 
electronic mail and we do not require all administrators to use only electronic transactions to 
submit, say, a purchasing requisition.^ There is always the option to use a paper form, fax, paper 
memo, messenger or telephone. 

This is rapidly changing. The option to use, or not use, the desktop computer will soon disappear. 
The end-user's personal computer will soon cease being a typewriter replacement and will become 
the end-user's only window to the university's administrative applications, electronic mail, 
analysis tools, information servers and collaborative work. Empowered users will accomplish all 
work and most communication and information exchange through their networked personal 
computers. The end-user's desktop will be the new center of the computing universe.^ Soon, our 
administrators, faculty, staff and students who do not understand and use their networked desktop 
computer in accomplishing their university role will become isolated, separated from the 
administrative and educational mainstream. 

Our end-users, our organizations and our technological infrastructures are not ready for this rapidly 
approaching computer-mediated future. Our users are struggling to master the computers already 
on their desks. Our support organizations are struggling to train these end-users.^ 

This paper addresses the importance of the end-user's desktop by: 

• looking at the university administrator's work environment and how it is changing 

• reviewing various user-support and training models 

• expanding the definition of end-user to include faculty and students as well as administrators 

• reviewing user-services experiences at The University of Chicago 

• proposing possible user-services models and organizations 

This is a complex subject involving cultural, sociological, organizational and technological issues. 
A short paper such as this can only explore one or two thoughts in any depth. There is sogpie 
interesting work being done in the private sector on this theme. Hopefully, others will tJike these 
ideas and use them to help us better understand how to build, support and utilize the human and 
technological infrastructures in our universities. 
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II. Administrators and Their Work 

Outside of our central organizations and the larger academic units, our administrators are "Lone 
Rangers," — one person tending to most administrative matters such as purchasing, personnel 
administration, budget management and report preparation. We have observed that these 
administrators are generally interrupt driven in that they must deal with the current demand or crisis 
crossing their desk."^ The administrators are isolated in that they are the only person in their unit 
with such responsibilities.^ Since these administrators report up through their organization, there is 
little reason to talk to peers in other units — so cross training is limited. We have also observed that 
these administrators have no forums in which to share common problems and have no champions 
to advance their agenda. 

The administrative work environment has been relatively stable for many years. With the 
introduction of PCs and networks, the technological knowledge and skill required to perfonn as an 
administrator have increased— but individual administrators have not yet fully incorporated 
networked PCs into their daily work. Since our administrative systems are paper- or mainframe- 
based, there is limited organizational or peer pressure to master networked desktop computing. In 
addition, the required network and PC resources are not in place and the required organizational 
support and direction is not available. 

In our work with campus organizations, we have loosely identified three general categories of PC 
user: the early adapters, the laggards who will never be able to, or will not, adapt and the 
remaining 'adapt as required' majority.^* This majority will use technology if they can see that it 
adds value, if they are trained and if there is an organizational expectation for its use.*^ The early 
adapters, on the other hand, are the ones who love technology for its own sake. Given the rapid 
change we will be experiencing, a challenge facing user- services is to adequately train the *adapt as 
required' majority and to somehow leverage the talent, enthusiasm and knowledge of the early 
adapters. More on this later. 

III. Rapid Change 

The administrator's world is rapidly changing. Figure 1 presents a model of the administrator's 
environment tcxiay while Figure 2 gives a comparable view of tomorrow's environment. 



Figure I . User Model: Today 
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Figure 2. User Model: Tomorrow 
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Many of the change elements in the 'tomorrow model' are already here. To me, these change 
models support the idea that, like it or not, we are moving toward an electronic comiTiunity where 
we will work, communicate, teach and learn through our desktop. Our organization's effectiveness 
will depend upon successful interaction through the desktop. 1\Kiay the desktop is inconsequential. 
In the rapidly approaching future, the end-user's desktop is critical. 
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IV. Disappearing Applications and New Organizational Structures 



An interesting phenomenon is taking place. Our central applications are losing their identity to the 
end-users. Today, with our mainframe-based legacy systems, we log into, say, the purchasing 
system to initiate a purchasing transaction. Likewise, we take specific steps to log into a different 
system to inquire about a personnel matter. 

With the current commercial client-server applications available for the higher education market — 
which are based upon integrated relational database management systems — end-users log in 
through the network and select the transactions they need and are authorized to use. The movement 
between the various traditional systems, such as the accounting, personnel and student systems, is 
seamless. To th'e end-user (in this example a departmental administrator) there is one administrative 
system. The accounting, personnel or other central office that today *owns' the application and data 
and processes the paper transactions may, over time, become blurred into one central support 
office in the minds of the end-users.^ 

Needless to say, the disappearing applications phenomenon has some important implications for 
user-services, which will be discussed below. 

V. What Skills are Required? 

How do we prepare our end-users for the electronic organization of the future? Will our current 
employees make the transition? Do we wait, as one of our administrators suggested, to introduce 
new computer-based systems until all the people who do not use computers have retired? How can 
we train the thousands of future system users? 

What is required can be better understood if we consider the technical skills used by administrators 
over the years to record basic business transactions. As indicated in Figure 3, we started orY 
centuries ago with pen and ink and then moved to typewriters early in this century. In this 
simplified history, we moved to mechanical punched card systems in the 1940s, to electro- 
mechanical ledger card systems in the 1950s and to mainframe based systems in the 1960s and 
70s. Each of these changes required retraining and resulted in new organizational structures to take 
advantage of the new technologies. 

For example, most of the initial mainframe applications concentrated on eliminating manual clerical 
operations with a resulting organizational structure that concentrated data-entry personnel into 
relatively low-skilled units.^ 

PCs were introduced in the early 1980s; however, they had little impact on the typical organization 
because they were not networked, they were used to emulate dumb terminals, the users were not 
trained and the PC was not integrated into daily business activities. Later in the 1980s, 
networked personal computers were introduced. Application systems designed to take advantage of 
networked desktop computing power are being developed and installed in some organizations. 
Figure 3 suggests that the administrators need to master a well-defined, achievable set of skills to 
work successfully with networked PCs. 

This analysis implies that if we can bring our employees up to a knowledge and skill level adequate 
to work in the existing networked PC environment and ensure that this skill and knowledge level is 
maintained, then our end-users will be prepiired to successfully handle the additional technical and 
non-technical skills required as new organizations, redesigned procedures and new systems are 
introduced. In other words, if we are to successfully change our organization to take advantage of 
the enabling power of the new networked PC-based technological infrastructure, we must develop 
our human infrastructure. 
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Year Representative Required 

Introduced Technology Administrator Skills Remarks 



Centuries ago 


Pen & ink 


General penmanship 




1900s 


Typewriter 


Typing 




1940s 


Punched cards 


Typing 


New low-skill backroom activity 
evolves 


1950s 


Ledger card 
machines 


Typing 


Some ledger card activity moves 
from backroom to adminisu^ative 
offices 


1960s 


Mainframe 
computers 


Typing, Some data enU-y and inquiry 
through dumb terminals 


New organizations created: data 
entry, programming, computer 
operations 


1980s 


Personal 
computers 


Typing, word processing, spreadsheets. 
Some data enU-y and inquiry through 
dumb terminal emulation 


PC used as a personal tool. 


Ute 1980s 


Neiworkal 

personal 

computers 


Word-processing, spreadsheets, on-line 
transaction submission, inquiry, 
reporting, e-mail, network navigation, 
collaborative work 


Changing organizations. New 
communications su^uctures. 



Figure 3. Representative Required Administrative Skills 



Once our end-users are functioning adequately in the networked PC environment, what additional 
technologies will they be required to master? Keeping in mind that predictions are difficult, 
especially about the future, I suggest that possibilities include multimedia, personal digital 
assistants and virtual reality. Multimedia and digital assistants can be considered an outgrowth of 
PCs and adequately qualified PC users should be able to master either or both as the need arises. 
Virtual reality will probably remain in the entertainment realm for the next few years. Anyway, 
most of our udminisu*ators have sufficient real reality to be bothered with the virtual kind. 

VL Who are the End-Users? 

At The University of Chicago I would estimate that there are from 700 to 900 or so users of our 
corporate administrative systems — with a user defined as one who prepares transactions for 
submission or has on-line access to the corporate systems for transaction entry or inquiry. There 
are, of course, many more account managers, researchers, faculty and others who have account 
management or other responsibilities and receive periodic paper reports but have no direct interface 
with the systems themselves since this is typically handled by the departmental or other 
administrator as described above under '^Administrators and Their Work.'' 

This is rapidly changing. With the new administrative systems we will eventually purchase or 
possibly build and the administrative procedures and processes we will reengineer: 

account managers will have on-line access to their accounts and can initiate 
transactions directly 

• researchers will have direct access to information on their sponsored research accounts 
and can, if they wish, initiate transactions 
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faculty will have on-line access to appropriate class and student records as well as 
access to their accounts and the ability to initiate transactions 

employees will have some type of direct access to their own personnel records 

students will have on-line access to their own academic and financial records and will 
be able to update, on-line, certain information such as their various addresses 

Eventually, virtually every employee and student will have some type of access to our corporate 
administrative systems or to portions of the data. As these new users are given access we will 
move from hundreds of users to thousands. For The University of Chicago, with 11,000 or 
so students and approximately 10,000 employees, there is a potential of having up to 21,000 
end-users. 

VII. Required End-user Desktop Resources 

If we consider the networked PCs in place today, we will find that e-mail, remote information 
access and desktop PC applications are a common denominator among most end-users. What 
today seems to set faculty, staff and students apart as far as PC usage is concerned is that some 
administrators have access to corporate administrative systems or other function specific systems, 
some faculty use computers in the classroom and in their research and students are special because 
they are students. 

If we set aside sociological issues (such as faculty generally not wuniing to attend classroom 
training and staff being reluctant to sit in a classroom with sharp, eager students), I believe that this 
division of faculty, researchers, staff and students, however defined, into separate groups for PC 
support is inappropriate. A different model, especially if we accept that over time virtually 
everyone will have access to and will use the corporate administrative systems, is to consider that 
all faculty, researchers, staff and students have a common core of PC resources that they must 
know and use to be productive members of the University community. This core includes access to 
a networked PC, access to a basic set of desktop Applications, access to electronic-mail, access to 
various networked information sources and services, and appropriate access to the corporate 
administrative systems. Implied is the required knowledge and skill to adequately utilize these core 
resources, the organizational and peer expectations that the core resources will be used by everyone 
and an organizational commitment that the core resources will be made available. 

In addition to the core resources there exist at least two special areas of PC usage: computers in the 
classroom and computers used in research. It seems that support for classroom and research related 
computer usage are special areas that will be best addressed on an as requested basis. This does not 
preclude having information technology specialists proselytizing the use of computers in the 
classroom; however, computers will be widely used in the classroom only when the push comes 
from the faculty themselves. That push will grow very rapidly once a critical mass of computing 
skill and knowledge is in place — when all faculty and students are actively using the core PC 
resources. 

VIII. End-user Support Requirements 

This paper, so far, has proposed that in our rapidly changing environment: 

We have thousands of end-users that must become proficient in a reasonably well- 
defined set of core resources 

All faculty, staff and students will work with about the same set of core resources 
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Once the core resources are mastered, the end-users are prepared to cope with the 
evolving networked PC-based technological infrastructure until some new future 
breakthrough occurs 

Bringing thousands of users up to an acceptable level of proficiency with the core resources and 
maintaining that proficiency is, needless to say, a challenge and requires a bold new approach. I 
propose that we look beyond the technology and recognize that we are really introducing 
organizational and cultural change — and then proceed appropriately. 

At The University of Chicago we have been very successful in moving entire groups into new 
technological environments. Examples include our President's Office'^ and the Publications,^ 
International Affairs, College Admissions and Special Events Offices. Our methodology puts great 
emphasis on individual, one-on-one coaching, relating the technology to the individual's work and 
establishing group expectations for system use. Traditional classroom training, when used in these 
change efforts, has been less successful than we would have liked. 

We have not been very successful in assisting isolated individuals to adapt to new technologies, 
especially administrators in remote academic departments. For example, we have installed e-mail 
and other network-based applications for such academic departmental administrators and they 
aren't used. We believe that the administrator's isolation, the difficulty in setting expectations for 
use and the lack of a critical mass of PC-based functionality havee contributed to this lack 
of success. 

The installation of electronic mail is a good example of our group approach. We always 
recommend a micro-based e-mail package. (QuickMail— but other similar products would work as 
well.) Micro-based e-mail is feature-rich, easy to use and is locally maintained on the front end 
within the group. Generally, everyone gets their e-mail connection and personal training in its use 
at the same time, which helps to set group expectations for use. We have installed QuickMail for 
hundreds of users and have always been successful— where success is defined as everyone in a 
group using e-mail on an on-going basis. 

We have not yet had an entire client group begin to use e-mail where pop-mail, mainframe-based e- 
mail or other non-micro-based e-mail was used. We believe the individual focus of these e-mail 
applications, when compared with micro-based e-mail, has contributed to this lack of success. 

Our directions and experiences have been substantiated by the literature, including: 

Local, focused, just-in-time assistance is the most effective end-user support. The support 
person must provide business-related, context-sensitive coaching and training^^ 

Most learning takes place on-the-job, classroom training is typically not effective^^ 

We must change our organizational structures to accommodate and exploit what is valuable 
in information technology if we are to bring about the information technology revolutions^ 

IX. One User-support Model 

One approach to providing the required desktop PC support to end-users is to recognize that there 
are two very different tasks to be accomplished: 

I . Bringing end-users up to an acceptable level of proficiency with the core resources 

IL Providing on-going support to end-users to maintain and increase proficiency 

Task I is best accomplished in natural groups— such as all faculty and staff in a department or all 
staff in an administrative unit. Bringing together selected administrators from many different 
academic departments, providing training to one person from a unit and similar splintered 
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approaches will not be successful due partially to the absence of the group expectations and mutual 
support which exists when groups are "converted." If possible, the intervention to introduce new 
technology to a group should be timed to coincide with the group's connection to the network or 
other significant event. 

Our experience indicates that the requirement for support when using the proposed Task I approach 
drops off rapidly after a short period of intense personal support. 

The long-term Task II support can be provided several different ways. We provide a range of 
support, depending upon the requirements and resources of the unit. For example, we provide on- 
call support for individuals and small units while Uu'ger units have resident experts whom we have 
trained to provide front-line, just-in-tjme support, with our organization providing backup. We do 
have a problem that needs to be addressed: the contribution by our resident experts, who tend to be 
regular staff with job pressures like everyone else, are 'lot officially recognized in their job 
descriptions or by the University — and occasionally not by their bosses. 

Staffing for end-user support organizations must have an information technology background, 
understand the university's business processes, know the organization and have excellent people 
skills. According to the literature, most traditional classroom training and hot-line support 
personnel lack the educational and business experience to be successful in this newly-defined 
user-support role.^"^ 

X. Summary 

After years of spending $millions on PCs and related technology with no pay back, we are poised 
for a breakthrough. This breakthrough will be driven by our institutions achieving a critical mass 
of networked PCs and the implementation of new prcxesses and organizations to take advantage of 
the potential these new technological and strengthened human infrastructures provide. The 
technical infrastructure to achieve this breakthrough is, for the most part, available and could be 
purchased today, given sufficient funding. The human infrastructure required to achieve this 
breakthrough is a different matter. For years we have cropped PCs on end-users desks and 
assumed that somehow they would learn to use them. For yeiirs we have treated the introduction of 
PCs, networks and related technology as if it were another office tool, like a typewriter. For years 
we have skimped on training and support, forcing our end-users to learn from one-ar.other and 
support themselves. For ye^us we have tolerated non-use of technology. As a result, our end-users 
and our organizations are not prepared for the future. Many are struggling to get by with today's 
technological demands. 

The challenge to our universities is not technological. It is a human challenge. We must take bold 
steps to prepare the entire organization for the future. An initial step is to focus on building the 
human infrastnicture. A first step in building this human infrastructure is proposed by this paper: 
do whatever is necessary to bring the end-users up to an acceptable level of proficiency with the 
core resources. And since we are really dealing with organizational change and the setting of 
organizational expectations, we need to approach this initial task by ''converting" groups rather 
than individuals. 

Ongoing support is also very important. If we are successful in getting the core resources into use 
by all end-users, we will create a tremendous demand for help in mastering new tools and doing 
new things in addition to assistance in solving routine problems. 

The possibilities are exciting. If we are successful in getting an entire university to use at least the 
core resources, we will build a synergy that has never existed before. Imagine the faculty, 
students, and staff linked together electronically, supported by new administrative and other 
support organizations. This will lead, over time, to new approaches in education, research and 
administration with u^emendous benefits to us all. 
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1 Many of our electronic transaction systems are actually main frame -based legacy systems 
with the desktop computer substituting for a *dumb terminar. For this paper such systems 
are considered in. the same light as the typewriter. They have served thei^ v-^rganizations well 
and will continue to do what they were designed to do; however, such systems are not part 
of the end-user desktop environment this paper is addressing. 

2 The phrase '\ . .new center of the computing universe." first appeared in John P. Halloran's 
and Brian S. Pappas's article titled **Micro Management" in the April 15, 1993 issue of CIO 
magazine. Halloran and Pappas are affiliated with Nolan Norton & Co. 

^ A major theme of discussions in the User Services Special Interest Group meeting at 
CAUSE93 was that our user services organizations are underfunded, understaffed and that 
our organizations do not understand the importance of end-user support. 

This discussion focuses on the 'business' administrator. In academic units there is usually 
a 'student affairs' administrator who faces similar isolation issues. 

^ For a discussion of administrative organizational issues see Therese Nelson and James 
Porter's article, ''Desktop Computing Power: Issues and Opportunities" in the Summer 
1991 issue of CAUSE/EFFECT, 

^ Halloran and Pappas, in the article mentioned above in Note 2, suggest that the early 
adapter category is 20%. Chris Pickering, in his December 1992 article in CIO magazine, 
"Preparedness Training," suggests that laggards make up 16% of our employees. 

^ In "Introducing Technology to Senior Executives: Theory and Practice — a Case Study" 
{CAUSE92 Proceedings) James H. Porter suggested that desktop computers will be used 
by executives and other senior managers when the applications are easy to use, are 
meaningful to the executive, and a "critical mass" of functionality is available such that the 
executive turns on the computer first thing in the morning and uses it throughout the day. 

^ If our end-users are empowered through on-line, integrated systems into which have been 
embedded the university's policies, processing rules, edit and audit rules and legal 
requirements, will this result in major changes to the traditional roles and organization of 
our central administration? Do our administrative processes have to be supported by 
systems broken into the traditional financial, student, human resources and 
fund-raising modules? 

This reduction of clerical personnel was offset by the new data-entry, computer operations 
and computer prograinming organizations. The apparent savings in clerical costs were used 
by our systems organizations to justify new and improved systems. Unfortunately, using 
computers to reduce clerical costs is still expected by many of us while the major benefits 
from computing are in improving organizational effectiveness and enabling new 
organizational sH'uctures. 

The typical PC in our organization is used for word-processing and spreadsheet 
applications. Some use the PC to access information on our legacy systems over the 
telephone lines or via the campus network. A growing number use electronic-mail as their 
primary communications medium. However, none of these activities are yet fully integrated 
into the way an administrator works. 

1 1 John Halloran & Brian Pappas in the article referenced in Note 2 above. Also, "Wanted, 
MBAs for the Help Desk" in Information Week, October 18, 1993. 

1 2 Kavin Moody of the Bank of Boston in IlS Amilyzer, September, 1992 
1 ^ From What Presidents Need to Know published by CAUSE, 1993 

1^ Naomi Kartin in "Mind Your Own Business" published in Stratef^ies for End-user 
Computin^i: QED Information Sciences, Wellesly, MA, 1990 
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Abstract. The University of Pennsylvania is one of the first universities to 
link the re-engineering of business processes and the development of an 
architectural foundation for information and systems. The presentation explores 
that linkage, focusing on planning for flexibility in a fast-moving world, 
aligning information technology with business goals, and negotiating consensus 
in a radically decentralized institution such as Penn. 

The presentation draws on lessons learned in a multi-year effort by Penn's 
Division of Finance and Office of Information Systems and Computing. The 
two partners are leading an effort to make Penn*s business processes faster, less 
expensive, and more flexible; develop an information technology architecture of 
principles, models, and standards; and acquire a new generation of business 
systems, beginning with a new financial system. 
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Architecture and re-engineering: Partnership for 
change at the University of Pennsylvania 

Penn believes that finding new ways to manage the institution is critical to the success of the 
academic mission. With costs growing faster than revenues, demographics shifting, and Federal 
grants in shorter supply, the belt has to be tightened somewhere. The University of Pennsylvania 
is committed to cutting costs and boosting quality on the administrative side in order to redirect 
funds to research and instruction. We've started an approach we call "Project Cornerstone." It 
brings together three related efforts — Total Quality Management, business process re- 
engineering, and information re-engineering. 

The partnership. A many threaded partnership is at work. The organizational partnership 
links Penn's Division of Finance and the Office of Information Systems and Computing. Their 
methodologies are also linked. The Division of Finance is reciesigning broadly conceived 
business processes to make them faster, less expensive, and more flexible. Information Systems 
and Computing is developing the principles, architectures, and standards for a new generation of 
systems that will support the new processes. James Martin and Company serve as consultants. 

Progress to date. Penn has finished its first re-engineering effort in procurement and 
disbursement and its second in compensation. We have ''completed" the principles and 
architectures, recognizing that they are living, ongoing efforts. We are deep into negotiation with 
vendors to provide an integrated set of business systems that will support the new ways of doing 
business. The first system will be financial and the first application will be procurement/ 
disbursement. 

In this paper. This paper focuses on business re-engineering at Penn and on Penn's 
information technology principles and architectures. The paper pursues three themes — aligning 
information technology to the business, planning for flexibility, and negotiating consensus. (Penn 
is radically decentralized; we have twelve schools v/ith substantial independence. Consensus is 
part of our organizational culture.) We offer you our experiences and the lessons we've learned. 

The machinery 

Business re-engineering. Business process re-engineering is the fundamental, start-from- 
scratch, redesign of business activities. Processes are conceived broadly, across organizational 
boundaries. They start with a customer and are not complete until that customer is satisfied. 

Total Quality Management. Total Quality Management is a more incremental approach to 
continuous improvement, also focused directly on the customer. 

Information engineering. Information engineering is a set of tools and techniques to create a 
common basis of decision-making for business people and information technologists. 
Information engineering is based on principles, or basic beliefs about how the institution uses 
information technology, and on architectures, or frameworks for that technology. There are three 
of these architectures — information, business systems, and technical infrastructure. On that 
foundation are built policies, standards, plans, and, finally, systems that work together and share 
data. 
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Technology In supporting role. Information technology is seen as a facilitator, an enabler, 
of the improvements identified in business re-engineering. Technology cannot substitute for 
organizational and cultural change. U can, however, create an infiastructure for data sharing, 
flexibility, and ongoing measurement of quality. A new mix of technologies and techniques are 
required. If we want business processes that are flexible and responsive, our technology 
processes must be equally flexible and responsive. We will have to meet the challenge of 
constant change as we develop and maintain the new systems. 

The chart shows the interdependencies that are the focus of this paper. It shows the driving force 
of University direction and business needs and the intimate linking of business process re- 
engineering and information engineering. The goal is new ways of working, supported by new 
information systems. 
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Business re-engineering 

Re-engineering isn't warm, friendly TQM. How do you get 
people to play when the stakes are so high? 

How high ARE the stakes? Many groups at Penn have launched Total Quality Management 
projects to improve specific problems. Project Cornerstone has depended heavily on the TQM 
teams' analysis of existing processes and has benefited from the discipline and cohesiveness that 
TQM teams bring to an institution. 

Re-engineering, however, is a very different approach. You try to rethink the process, the 
business, from scratch. You have to nurture absolutely outrageous ideas and make people 
comfortable exploring the unexplored. For real improvements, you have to tackle processes that 
are broad enough to have significant impact, which means crossing organizational boundaries. 
Crossing these boundaries is very threatening. You have to negotiate ownership and new roles. 

Re-engineering requires much more than changing the flow of work. To change a process 
successfully you also have to change people's jobs, skills, rewards, tools, organizational 
structures, and to some extent, their values and beliefs. 
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Watching ourselves change. The rest of the campus was grateful at first "it's not me." The 
rest of the Executive Vice President's organizations were glad they weren't the first to try re- 
engineering, and the schools were convinced it was the central organization that needed to 
change. In the Division of Finance, we were not happy to be the first in the barrel. We knew, 
however, that if we didn't take control of our future, someone would do it for us. 

The core team had to push itself and others to define the first process broadly enough. We were 
accustomed to thinking of two central offices, "Purchasing" and "Accounts Payable," when, in 
fact, the procurement/disbursement process occurs across the entire campus, in schools, 
departments, and other offices. 

We had to blow the roof off our own expectations. Our first estimates were nowhere near the 
40% staff reductions and 25% budget cuts we now believe can be achieved in procurement/ 
disbursement. 

Most striking, the Division of Finance has a new conception of its place at Penn. We eventually 
found ourselves willing to say, "Lx)ok, our finance function happens every day out in the schools 
and centers. And, frankly, our notion of being in the compliance business, double and triple 
checking, doesn't add a lot of value." We've designed a "paperless" procurement/ disbursement 
process that lets the people in the local units buy things, receipt the goods, and release payment. 
The central organization can now focus on identifying the best vendors and negotiating the best 
prices. 

The energizing force. As we changed organizationally, we saw ourselves changing 
personally. We believe, in fact, that this is the energizing force that gets people excited about re- 
engineering. We saw changes in our management styles, our focus, and our personal interactions 
with each other and with our customers. The energy comes also from marshalling forces. We 
began pulling together alliances of people who like a challenge and have the nerve to do 
something about it. We sought out people who can deal with uncertainly, as we experimented our 
way through a methodology new to us — to a result none of us could predict. We also needed 
people who were willing to take hits from the Penn community, who let us know in no uncertain 
terms when we were not communicating clearly or inclusively enough. 

We tried hard to eliminate the fear of failure within the core teams. We tried to recognize 
movement toward our goal, not just achievement of the goal. We believe we built trust, respect, 
and commitment. Penn operates slowly, by consensus — but within the core teams we succeeded 
in agreeing to disagree. The nature of re-engineering — nurturing the outrageous in search of new 
ways of doing things — runs counter, in fact, to a culture of consensus. An outside facilitator was 
key to making all this happen. He encouraged us, kept us on track, and kept pushing us past our 
own assumptions about the way things have to be done. 

Getting it done. We constantly walked the line between Penn's consensus style of drawing 
others in, inviting them to join teams, paying courtesy calls — and just moving forward with what 
we knew we had to do. We targeted key people and systematically argued the case that they were 
part of a broader business process than they were accustomed to considering themselves part of. 
We demonstrated the links with the process diagrams from the architecture effort. The diagrams 
are a two-edged sword. On the one hand, they depersonalize the business process, so you can talk 
about it without getting immediately into questions of turf. On the other hand, they are so 
impersonal that you have to reanimate the process, give it a human face. 

We insisted on having fun. One of us had second thoughts, though, when we told a large and 
very solemn group that we didn't need a new payroll/benefits system; we could all be bar-coded 
and pass by proximity readers in the morning — and no one laughed. 
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Information technology principles 

I'm delighted when people throw the principles in my face. 

What do the principles do? The quote is from co-author Robin Beck, wearing her Director 
of Applications Development hat. She finds, to her uncomfortable pleasure, that people throw the 
principles at her when they want something done or want it done differently. The principles have 
become a rallying cry in some quarters at Penn. 

The principles state Penn's beliefs about using information technology to solve business 
problems. We came up with twenty-six principles, in five categories: data, applications, 
infrastructure, organization, and an overarching general category. Here's an example of a general 
principle (see appendix for the entire set): 

Cost effectiveness. Information technology must be cost effective 
from the perspective of the University as a whole. 

For each principle, a rationale is stated and specific implications listed. One implication of this 
principle is that you have to take the entire life cycle into account, not just the cost of buying the 
technology in the first place. 

The principles are a link, a bridge, between the business people and the technologists. They 
attempt to make assumptions explicit, which helps both sides identify points of conflict and 
perhaps start resolving them. The principles are the foundation on which the architectures, 
policies, standards, plans, and systems are built. They're a stable base that lets those other 
components be as flexible as they need to be. 

Finding the sweet spot on the bat. The principles were the first component of information 
engineering to which the larger Penn community was exposed. We encountered a great deal of 
thrashing and negotiating of expectations as we unveiled the draft set of principles and began, 
seeking feedback and ratification. We had to keep telling people what the principles arent. They 
aren't standards, aren't policies, aren't plans. Until people saw real evidence that these additional 
components would fall into place, they told us the principles were "not useful." We also had to 
keep reminding people that the principles are meant to be used in combinations, not separately. 
People would focus on an individual principle and tell us it's "not useful." The organization 
principles turned out to be the hardest. They were the hardest for us to develop and they stirred 
up the most passionate critique in the community. We believe we were running into the fact that 
organization is far more complex than technology. 

When is enough enough? A piece of advice: Don't set yourself up. Don't let substantial 
discussion with a variety of groups count for nothing because in the end not everyone ratifies 
every principle. You have to be inclusive. You have to seek both formal and informal feedback. 
You have to really listen. That's your part of the bargain. But the feedback process itself won't 
come to a logical end. At some point the sponsor has to step in and say, "Thank you, that's 
enough." 

Language. Another piece of advice: Avoid high-sounding, cover-all-the-bases language. If you 
want people to use the principles, you have to write them so they can be remembered and 
repeated. They need to be short and sweet, almost slogans. (We confess we fail this test.) And 
don't let the committee writing show. Work hard to keep the group effort from obscuring the 
voice of the document and diluting the power of the message. 
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Building on the principles. The information engineering methodology guarantees tight links 
between the principles and the next component, the architectural models. We checked and 
rechecked the principles against the evolving architectures — to make sure the architectures were 
true to the principles, but also to make sure 3ie principles held up. It's necessary however, to 
communicate that connection to the larger public. Again to our uncomfortable delight, the 
community demanded to see the links between the lofty principles and the down~on-the-ground 
architectural models. 

Now that the architectures are complete, the process becomes far more public and diffuse. We 
are making an effort to recruit key people and seed key efforts. We target planners, for example. 
We want them to post the principles on the wall on big sheets of paper and invent exercises that 
take the principles into account. We try to draw in advisory groups. Tne first order of business 
for our brand new Data Policy Committee, for example, is to build a living structure for the data 
stewardship principle: 

Data stewards. Data stewards are responsible for ensuring the appropriate 
documentation, collection, storage, and use of the administrative data within their 
purview. 



Architectures 

An information technology architecture isn't a product. It's a 
process, 

— Gartner Group 

Three architectures. As with the principles, it's important to say what the architectures 
aren't. They aren't a pulpit to preach a particular planning methodology. They aren't a vehicle 
for technology for its own sake. They have one overriding objective — to improve the 
performance of the business. They spring from business purpose and are refined with one or two 
business themes such as faster turn-around or better service. 

Penn has developed three architectures — information, business systems, and technical 
infrastructure. All three are models, or frameworks, from which will flow policies, standards, 
plans, and systems. The architectures themselves flow one from the other: 

• The information architecture includes an enterprise-wide data model to help Penn 
understand what data it needs. That's mapped against an enterprise-wide process, or 
activity, model that helps us understand what the organization is doing. Reconciling the 
two ensures that actions will be supported by the right data. 

• The business systems architecture lays out the comprehensive set of information systems 
and data stores that are needed to carry out Penn's specific business processes. The 
systems are identified without regard for what's already in place or how the pie is 
currently sliced. 

• The technical architecture is a blueprint of the hardware, software, and communications 
components that will be necessary to implement the first two architectures. It's not a buy 
list, but a model from which standards and products can be derived. 

Focus on the technicai architecture. The diagram delves more deeply into the technical 
architecture. It illustrates four of the streams that feed the architecture. University direction and 
business needs are paramount. The principles are the second stream. Penn's current, de-facto, 
architecture — the third stream — greatly affects our migration strategy, so we did a systematic 
inventory of the current Penn environment. To research the fourth stream, technology trends, we 
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hosted a campus-wide series of forecasting forums, drew heavily on our Gartner Group 
membership, and visited a number of software and hardware vendors for non-disclosure 
briefings. From this raw material we crafted three architectural alternatives: a conservative one, 
an aggressive one, and one that falls between. 

Technical architecture- 



blueprint for technology choices 
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Where to start? To avoid paralysis, we fixed some components while we moved the rest 
around. In our case, the campus-wide network was already stable and in place and we quickly 
fixed the type of database we wanted. Our consultant greatly simplified our job. He convinced us 
there's a fairiy small set of basic architectural alternatives. Our job was to see which ones make 
sense for Penn. Place holders were another way we kept things manageable. We recognized there 
were areas of the architecture (networking and office systems, for example) that required a more 
detailed approach, a more participatory approach, or an approach that took academic needs more 
explicitly into account. The core team dealt with these at a high level and then handed them off 
to other groups. 

Planning for flexibility. It's feedback loops that permit flexibility and nimbleness. As the 
diagram ^low suggests, we expect the principles to remain relatively stable. The architectures 
and business needs are less stable, since the environment is constantly changing. It's necessary to 
track and pilot emerging technology. Penn has no advanced technology group, but Information 
Systems and Computing makes an effort to coordinate and share the fruits of campus- wide pilot 
efforts. The ongoing technology forecasting forums are another centrally-facilitated effort. A 
strong education campaign is also required to build excitement and awareness. 
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Planning for flexibility 
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Continuous effort 



Breathing life into the architectures. Architecture — arcane at worst, cryptic and jargon- 
ridden at best — is a tough sell. To capture hearts and minds, you constantly have to make the 
business case — service, productivity, costs. Penn's senior management are fortunately taking the 
realistic approach that exact numbers can't be known at this point, but orders of magnitude can 
be known and must be demonstrated. 

It's useful to have a short, compelling article to hand out. We use Davenport, et al., "How 
Executives Can Shape their Company's Information Systems," Harvard Business Review, 
Mar/April 1989. 

We've learned that some people respond to images and some to text, so we've tried to 
communicate the architectures both ways. Our Executive Vice President, brand new to the job, 
found our highest-level, one-page process diagram of Penn helpful as she tried to understand her 
new organization. She cut quickly to the chase: These particular functions have huge numbers of 
inputs and outputs; I should look for opportunities there. And if there are so few inputs and 
outputs to this function, why are so many people working there? 

We're sitting on a treasure trove of data — and need to make more effective communal use of the 
vast store of diagrams and inventories. They could save other people a lot of work, and could 
become an important shared lexicon at Penn. 
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Wrap-up 



Keeping the partnership alive. For the partnership to thrive, the Division of Finance and 
the Office of Information Systems and Computing must understand each other. The technologists 
need to understand what business Penn is in. The business people need to understand why and 
when Penn should invest in information technology. Both sides have invested blood, sweat, and 
tears to understand each other well enough to get to this point. Both are concemed that their own 
side will treat the effort as a project with an end point and wrap party rather than an ongoing new 
relationship. Both sides are working hard to institutionalize some of the formal and informal 
communication channels that have sprung up. A particularly difficult problem is how to maintain 
the hard- won kernel of knowledge of each other's fields, which won't stay current long in today's 
fast changing environment. And what's "enough" to know? 

A role for CAUSE. Both CAUSE and its business counterpart, the National Association of 
College and University Business Officers (NACUBO), could be helpful to the growing number 
of partnerships like this one. CAUSE could go much further than it does to help information 
technologists teach themselves about business and education trends and stay current on what's 
happening in Washington. NACUBO could return the favor. 

For more information. For more information about Project Cornerstone, contact Janet 
Gordon or Robin Beck. For a copy of Information Systems and Computing's long-range direction 
statement, which is based in large part on Project Cornerstone, contact Linda May. 

Janet Gordon Robin Beck Linda May 

721 Franklin Building 265C, 3401 Walnut St. 230A, 3401 Walnut St. 

Philadelphia, PA 1 9 1 04 Philadelphia, PA 1 9 1 04 Philadelphia, PA 1 9 1 04 

2 1 5-898-6693 2 1 5-898-3028 2 1 5-898-0005 

gordon@al.relay.upenn.edu beck@al.relay.upenn.edu may@al.relay.upenn.edu 



Appendix: Information Technology Principles 

General 

1. University assets. Information technology infrastructure, business applications, and data 
must be managed as University assets. 

2. Functional requirements. University priorities and business functionality determine 
investments in administrative information technology. 

3. Cost-effectiveness. Information technology must contribute to the cost-effectiveness of 
the business functions it supports and must be cost-effective from the perspective of the 
University as a whole. 

4. Policies, standards, and models. Policies, standards, models, and methodologies — 
based on the principles outlined here — govern the acquisition and use of data and infomiation 
technology. Regular update and communication are required. 

5. Investment criteria. Investment decisions (even those not to take action) must be based 
on business needs, cost-effectiveness, and consistency with standards and models. 

6. Training and support. Penn must put sufficient effort into ongoing support of its 
information technology assets. Skills and experiences from across the University must be 
leveraged and communication channels opened. 
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University Data 

7. Accuracy. University administrative data must be accurate and collected in a timely way. 

8. Security and confidentiality. University administrative data must be safe from harm 
and, when confidential, accessible only to those with a *'need to know," 

9. Ease of access. University administrative data must be easy to access for all groups of 
authorized users regardless of their level of technical expertise. 

10. Multiple uses. Penn must plan for multiple uses of University administrative data, 
including operations, management decision making, planning, and ad hoc reporting. 

11. Purposeful collection. A given set of data should be collected once, from the source, and 
only if there is a business need for the data. 

1 2. Common base of data. A common base of data must be created to facilitate sharing, 
control redundancy, and satisfy retention requirements. 

13. Documentation. Detailed information about University administrative data must be 
created, maintained, and made available. 

Business Applications 

14. Ease of use. Applications must be easy to use for both novice and expert users. Interfaces 
should be similar enough to present a reasonably consistent "look and feel." 

15. Adaptability. Applications must be easily adaptable to changing business and technical 
requirements. 

16. Data sharing. Applications must use a common base of well defined University data and 
reference a common repository. 

17. Ensuring data quality. Applications must help ensure valid, consistent, and secure data. 

Infrastructure 

18. Common communications infrastructure. Academic functions and administrative 
systems must share common data, voice, and video communications infrastructures. 

19. Connections within the University. The communications infrastructure must be 
standardized to allow reliable, easy interaction among individuals, work groups, departments, 
schools, and centers. 

20. Connections outside the University. The communications infrastructure must comply 
with national and international standards that allow reliable, easy interaction with those 
communities. 

21. Hardware and software choices. Hardware and software for administrative use will be 
limited to a bounded set of alternatives. This applies to desktop computing, application 
servers, communications components, application development tools, and data management 
tools. 

22. Emerging technologies. Penn must devote appropriate, coordinated effort to evaluating 
and piloting emerging technologies. 

Organization 

23. Data stewards. Data stewards are responsible for ensuring the appropriate documentation, 
collection, storage, and use of the administrative data within their purview. 

24. Process owners. Process owners are responsible for developing and maintaining the 
standards, structures, and business applications that ensure the quality and cost-effectiveness 
of specific business processes. 

25. Information Systems and Computing (ISC). Information Systems and Computing 
provides leadership, infrastructure, standards, services, and coordination that permit Penn to 
take full advantage of its information technology assets. 

26. Schools and administrative centers. Schools and administrative centers are 
responsible for creating data and using information technology to meet the objectives of their 
organizations. 
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Successful Planning from the Bottom-Up 

Eric Jacobson, Academic Computing 
Dolly Samson, Computer Information Systems 
Weber State University 
Ogden, Utah 



Abstract 

Most universities generate strategic computer plans from the top down, 
both conceptually and administratively. The process is instigated by 
high level administrators and begins with the general institutional 
mission and environment. Weber State planning goes in the opposite 
direction. Faculty are asked to describe their particular needs for 
computer and communication support and from the resulting list are 
abstracted common objectives and sharing procedures aiming at overall 
goals. This approach has produced a very practical, useable document; 
has evoked rapid change; and has increased cooperation across campus. 
The process is evolving into a potentially revolutionary departure from 
normal top-down management 
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University planning in general, and computer planning in particular, are regarded as 
explicit, self-conscious acts, initiated by senior administrators, derived from 
fundamental institutional priorities and effecting high-level policy decisions. 
Strategic Plans are awarded capital letters by university presidents. At Weber 
State University (WSU) we have experienced a different phenomenon. Without 
pretensions of anything more than immediate efficiency and common sense, a series 
of tactical decisions by faculty committees and administrators have accumulated 
into a document and a process which serves the institution as a strategic computer 
plan. "The Plan" was in effect before senior administrators knew of its existence. 
Comparison of the two approaches affords insights into the nature and benefits of 
the variety of acts which are called planning. 



Top-Down Planning 

Computer planning has generally been viewed as coming from above. In a recent 
paper concerning the adaptation of information technology to challenges facing 
higher education the authors state, "Information Technology planning needs to be 
integrated fully into an institution-wide strategic planning and management process 
... Senior leadership needs to be involved continuously ,„" (Rosser, Kunselman & 
Penrod, 1992.) Coughlin, in a survey of colleges and small universities, found that 
major computer resource and policy decisions were made by senior administrators 
on more than half the campuses, and by high level coordinating committees, such as 
a President's Council on more than 25% (1986). Faculty committees were used in 
less than 5% of the responding institutions. 

Planning can be top-down both administratively and logically. Administrative top- 
down procedures are rationalized by arguing that the broad participation necessary 
for implementation requires directives and incentives which come from the top. The 
first "lesson" listed as a guide to planning efforts at Rensselaer Polytechnic is "Top 
administrative commitment and participation are essential to obtain the 
cooperation of varied elements on campus and to arrive at decisions acceptable to 
these various groups," (Moss, 1982; p, 140), 

Logic based top-down planning consists of deriving computer needs from the 
fundamental goals of the institution. As Falduto, Grolden, Beyer, Conley and 
Detweiler describe it, "„, planning begins with the institution's mission, followed by 
identification of strengths and weaknesses, development of assumptioiis about the 
future, development of a vision of the future and goals consistent with the 
institutional mission, development of a timeline for achieving these goals, ,„ and a 
provision for assessment and feedback ,,,(1993, p, 19). Such logical development is 
meant to produce a plan which has general academic validity, which is coordinated 
with other components of the institution and which is adaptive to institutional 
challenges and opportunities, 
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From the high level, mission-based, vision successively specific sub-goals and actions 
are derived as the process moves down. Implementation of the plan occurs as these 
specific projects are finally accomplished. 

The recent planning effort at the University of Montana is a typical example a top- 
down effort. It was initiated by President George M. Dennison with the explicit goal 
of a "long range strategic information technology plan", (University of Montana, 
1992). After some preliminary work by separate constituency groups, a single task 
force, representing the widest range of university interests was formed to prepare 
the plan. Co-chaired by the Dean of the College of Education and the Vice President 
for Administration and Finance, the task force included 30 people: deans, directors, 
students and six faculty representatives. A critical first step in the work of this 
group was to develop a vision with maximum temporal and institutional scope. 
Perceived immediate needs of particular departments were purposely deferred in the 
interests of achieving this fundamental encompassing vision. After six rnonths of 
effort the task force produced a long range "Information Technology Plan" with six 
major goals for computer development and support administration. Goals are 
described briefly and are accompanied by few curricular, budgetary or 
implementation details, In true top-down spirit, various constituent groups have 
been filling out the Plan with these particulars over the last year.i 
1 

The Weber State Experience 

Wandering in the wilderness. By 1982 WSU had recognized the value of common 
goals and operational coherence in computer development, and thus the Coordinator 
for Academic Computing was charged with developing a campus plan. In 
collaboration with an ad hoc faculty committee the plan was written and 
disseminated in 1983. The plan was provided to all department chairs, was reviewed 
and blessed by the Dean's Council, and was approved by the Academic Vice 
President. 

The document, however, had no discernible effect on the campus and within three 
months of completion, fewer than ten people remembered that it existed. 
Curricular, budgetary and personnel decisions concerning computers continued to be 
based on departmental considerations without any institution-wide reference. A 
second plan was written in the following year with similar results. In hindsight these 
failures are easy to understand. The plan came from the Department of Academic 
Computing which had neither money nor authority to implement it. 



1 We appreciate the assistance of James E. Todd, Vice President for 
Administration and Finance, University of Montana, in helping us understand the 
planning process used at Montana. 
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Coherence and coordination in computer development was effected through informal 
discussions between individuals and departments, sometimes expedited through 
Academic Computing. The written plans appeared to be of no assistance in these 
efforts in consensus building, and general suspicion of high-level, comprehensive 
planning developed. 

Infusion One. In 1985 a special state appropriation of $700,000 was made 
available for general academic computing upgrades. Instead of dividing the money 
among the several colleges, the president and academic vice president appointed a 
special faculty committee to develop recommendations for how it could be best used. 
This committee solicited ideas from the faculty and was overwhelmed. It was clear 
that the majority of faculty desires for computer support could not be met and some 
hard decisions would be necessary. After sometimes rancorous discussion the 
committee arrived at a spending plan which excluded many particular requests but 
which was academically valid and reasonably coherent. 

Although the plan had many detractors, the general opinion was that it was an 
effective compromise. Independence from established departmental and college 
administrative structures did not appear to have handicapped the process, and 
some felt that such independence had encouraged rational discussion over political 
bargaining. 



Infusion Two. In 1986 a large, permanent budget increase was provided for 
unspecified improvements in educational computing. Again the academic vice 
president chose to allocate the money through a faculty group, outside the regular 
governance structure of departments and colleges, in this case the newly 
established Faculty Senate Computer committee. 

Following the model of a research grant board, this committee requested proposals 
from faculty for computer projects, with the initial expectation of simply reviewing 
these proposals and funding the most educationally meritorious. When the 
proposals arrived, however, the committee quickly realized that separate 
implementation of projects, as proposed, would be wasteful and ineffective. 

Redundancy abounded. For example, 15 departments (more than a third of the 
campus total) requested funding for the establishment of new personal computer 
labs. From one department came two separate proposals for labs from two faculty, 
apparently unaware of each other's requests. Several departments requested mini- 
computers, none of which provided additional seivice beyond that already available 
on campus. 

Many of the proposals were technically incomplete and unworkable. Hardware was 
requested with no applications software. For many projects no provision for 
installation, power conditioning, remodelling, system maintenance, or other 
essentials were made. Many good projects risked early demise, because there was 
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no space to house them, or funds to keep them in operation, or technical expertise to 
maintain them. At a more subtle level, it was apparent that inappropriate 
hardware or software was being requested for otherwise, valuable projects. 

Instead of a simple reactive role of funding some projects and not others, the 
committee decided to get actively involved in using the money to improve computing 
on campus. The goal became the efficient, workable implementation of the good 
ideas contained in the proposals. In other words, the committee redefined its role 
from one of funding computers to one of implementing curriculum improvements. 
Proposers were asked to provide more explicit and complete descriptions of the 
educational value of their projects. From these discussions the committee was able 
to forge a coherent development strategy. 

Where common values could be ascertained, it was possible to propose facility 
sharing, e. g. a single pc facility to support history, social sciences and English for 
common data analysis, CAI and word-processing needs. In cases where such 
sharing could be agreed upon, the committee negotiated with Deans and support 
departments to obtain space, remodelling funds and operational support which 
would be necessary for success and which had not been adequately accommodated 
in the original proposals. The value of these larger, shared projects which helped 
several departments and thousands of students was easy to demonstrate to Deans, 
and their budgetary and personnel support greatly extended the original monetary 
allocation. 

Discussion of educational intent revealed a natural temporal ordering which allowed 
priority setting and valid scheduling of projects. Some curricula were not ready for 
the requested projects, and the committee found it possible to concentrate funds on 
those areas where there would be an immediate impact. And, of course, some 
projects did not merit funding and the focus on educational goals helped emphasize 
their shortcomings. 

Using the proposals as a starting point for discussion and negotiation, then, tlie 
committee developed its own comprehensive design intended to accomplish, i^s much 
as possible, what the faculty had desired in the first place. Through several 
iterations the design was discussed and refined by the original project proposers and 
finally adopted and implemented. 

Discovering a plan. The campus computer design which emerged fi-om this 
allocation process became, of necessity, a long term commitment. The new VAX, 
the large new pc labs acquired through the allocation were major investments which 
would focus expenditures and activities for several years. The committee also 
became committed to the procedure which had been established for allocating the 
yearly budget: request proposals, integrate proposals into a coherent design, 
implement the design. Although the system was founded on academic priorities, 
encouraged campus-wide cooperation, reduced redundancy and moved toward long- 
term stability and commitment, the terms 'strategic' or 'plan' were never used. 
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Finally, in 1990 the concept of a strategic plan for computing was explicitly 
introduced in a request from the President's Council The Council sought some 
guiding principle for resolving the chronic, and sometimes impassioned, funding 
requests for student record systems, financial record systems, and academic 
computing. Vice presidents for Business, Student Affairs and Academic Affairs 
were each asked to develop long-term computing plans. Responsibility for creating 
the academic plan was accepted by the Faculty Senate Committee, and they 
approached the task by simply modifying the well-established fund allocation 
process. 

Questionnaires were sent to all faculty asking them to state their specific needs for 
computer support. Departments were asked to meet to discuss these 
questionnaires and individual responses to it to prepare departmental statements of 
need. These department reports were reviewed by College committees in the 
preparation of College reports on computer needs, which in turn were passed on to 
the faculty senate committee. Areas of University-wide interest, networking, 
mathematical and graphics processing, word-processing, computer-based- 
instruction and student labs, were identified in the initial survey results and groups 
of interested faculty were asked to develop coherent plans for meeting these needs. 

The completed Plan described 61 major projects in 6 general university-wide 
categories and within each of the 7 colleges. In addition many smaller scale projects 
were described within individual departments, A total of $6 million and a permanent 
budget increase of about $600,000 would have been necessary to fund the entire 
Plan, (Weber State University, 1991). 

Like the designs for fund allocation from earlier years the "Plan" was founded on 
very specific, concrete projects proposed for particular courses, educational 
programs or research projects, e, g. three DOS pc's with laboratory interface boards 
to be used by the 25 students enrolled each quarter in Psychology 343, 
Experimental Design. Also like the annual fund allocation designs, cooperative 
projects, broad goals, campus priorities were all abstracted from the specifics, 
rather than specified at the start. It was a bottom-up plan. 

Where the Plan differed from the fund allocation process was in its scope. Fund 
allocation designs were limited to the annual $200,000 budget at the Committee's 
disposal. The Plan, on the other hand, attempted to show how all computer money 
over three years, real and potential (and perhaps even imaginary), ought to be spent 
to optimize the academic program. Execution of the Plan would require budgetary 
support from Dean's and Department Chairs, and fund-raising support from the 
President and Vice Presidents, even though none of these administrators had had a 
direct role in the Plan's creation. 



O perating with the Plan. The initial Plan was adopted by the Faculty Senate in the 
Spring of 1991, The Plan was revised in 1993, (Weber State University, 1993) and 
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is undergoing revision again this year. Currency through yearly revision is a goal of 
the Computer Committee. 

The Plan has been used in three arenas. First, it has been used by the Computer 
Committee to allocate its yearly budget. Second, deans and department chairs, 
voluntarily and selectively, have based their own budgetary decisions on it. Finally, 
it has been the key rationale in appeals for increased funding. Nearly $.5 million has 
been allocated by the President's Council from University contingency funds in the 
last two years toward Plan implementation, and an appeal for a special legislative 
appropriation for some aspects of the Plan is under discussion in the Board of 
Regents. A review of implementation during the first academic year indicated that 
of the 61 major Plan projects, substantial progress was made on 17, some progress 
was made on another 17 and no progress was made on the remaining 27. 



Contrast 

Using a top-down approach, the President of the University of Montana directs an 
institution-wide group with a majority of administrators to develop a strategic 
computer plan. Through consideration of long term trends, basic institutional 
options and fundamental, common purposes, this group identifies major institutional 
goals. And finally, implementation details for accomplishing these goals are derived 
by user groups. 

WSU moves in the opposite direction. Implementation decisions involving a single 
faculty group coalesce into a planning process and ultimately an explicit plan. The 
process arises from a set of specific faculty projects, and grows to encompass 
academic computer development in general. No special support, prior to plan 
creation, is offered by Deans, Vice Presidents or the President. Can strategic 
direction emerge from such informal mechanisms? How does faculty grown 
organization differ from that mandated by administrators? 



A Closer Look 

Top-down planning is meant to integrate computer development within fundamental 
institutional goals by deriving particular projects from basic, mission-derived goals. 
Such derivation, however, is not rule bound, or even very constrained. Consider how 
a reasonably high level goal, such as "Instill in students an understanding of 
computing and computing applications," might be translated into specific actions, A 
new course offered by the Computer Science Department in fundamental computer 
theory and architecture might be developed and equipped. The College of Business 
might expand its offerings in applications software: databases, spreadsheets, and so 
on. Each department might be encouraged and supported in the development of 
computer learning experiences appropriate for its field. Even with strong consensus 
on the higher goal, there could be deep and genuine educational disagreements on the 
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best way to achieve it. The philosophical disputes would be exacerbated by 
budgetary competition and facility rivalry. Mission statements, by design, are an 
institution's common ground and therefore not very controversial. Disagreement 
increases with specificity. 

This problem can be attacked directly in the planning process. Arguments can be 
aired, disagreements resolved and specific decisions to do one thing and not another 
can be made-Computer Science gets the course, the other departments do not. For 
a plan of major scope there will be many losers as specifics are worked out and these 
losers may easily become disaffected from the plan and its implementation. 

Alternatively these disagreements can be avoided by not forcing the process into 
specifics, by leaving the plan at the level of broad goals meant to guide decision- 
making informally. Given the putative goal of increasing computer understanding, 
deans, curriculum committees and others would do what they could to improve 
students' computer concepts as opportunities arose. Vague statements of goals 
with little clear impact on institutional decision-making, however, can be 
platitudinous and irrelevant to the real needs of faculty. 

If the plan develops top-down administratively, that is, is encouraged and supported 
by the president and vice presidents then the cooperation of faculty may be more 
likely, but it is not certain. As a matter of fact, the top-down approach contravenes 
the traditional role of the faculty as masters of the academic program. Faculty are 
hired and tenured as independent, responsible professionals whose job it is to set 
curricular and research goals. Generally they have developed their own ideas about 
the nature of computing support for academic work and may have little patience for 
a planning process which they perceive to be detrimental, irrelevant or slow and 
bureaucratic. Beltrametti in a somewhat different computing context recently used 
a bottom-up approach at the University of Alberta because of the delays and staff 
resistance which can accompany top-down, manager-directed planning, (1993). 

WSU's bottom-up approach avoids some of these problems. Being based on present 
curricular needs as stated by the responsible faculty it has immediacy and 
relevance. Since the process begins, rather than terminates, with concrete project 
descriptions, the elapsed time fi-om funding approval to complete implementation is 
very short (typically no more than six months). With the narrow, curriculum- 
specific focus, the projects are very low-risk. Nearly all of the projects are 
implemented successfully, and have immediate demonstrable academic benefits. 

The process is open and collegial, and therefore engenders a high level of trust among 
faculty. One remarkable consequence of this trust is a reduction in total funding 
amounts of the Plan and its precursors over the last 3 years. Apparently 
participants feel less inclined to exaggerate needs and pad budgets, since the real 
needs will be perceived and sympathetically viewed by colleagues. Decision making 
on funds has become concomitantly more difficult, however, since automatic 
rejection or trimming of bloated projects is no longer possible. 
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The discussion of specific projects within a broad faculty forum has helped 
individuals discover and appreciate the work of others, and has thereby fostered 
cooperation and inter-departmental sharing. Software standards have been 
established for faculty and student use. Coordination of hypermedia projects has 
begun under the auspices of the Instructional Technology Office. An intra- 
departmental effort has been initiated to combine and upgrade UNIX systems. Five 
of the largest student labs have combined into a joint administration. The basic 
design for the universal campus network was initiated and implemented through the 
academic planning process. 

This is not to say that a miracle of selfless sharing has been wrought. There remain 
individualistic faculty and departments that have gone their own way. The 
experience at WSU, however, does show that coordinated projects aimed at general 
institutional goals can emerge from faculty deliberations on immediate curricular 
needs. Higher administrative direction is not a necessary condition for strategic 
thinking. 

A clear disadvantage of WSU's planning tactic is that its limited scope tends to 
discourage innovation. Departments and colleges focus on immediate, short or near- 
term computing needs and do not take risks to innovate for more far-reaching 
results. While individual faculty may design an innovative computer-related project, 
there is no incentive to implement a university-wide change. The collaboration and 
cooperation across departments and colleges fostered by the bottom-up planning 
process seems to encourage short-term and immediate sharing of resources. The 
Faculty Computer Committee chair has suggested that some portion of funding be 
set aside for higher risk projects, but this met with negative feedback from the 
Committee that specifically wanted to let individual colleges determine where the 
plan, and consequently the funding, would focus. 

The strengths of bottom-up planning are its immediacy, relevance and 
concreteness. A crucial condition for relevance at WSU was the budgetary 
allocation given directly to the Computer Committee starting in 1986. People were 
motivated to work at the process because it made a real difference in the 
accomplishment of particular projects. Probably no planning effort, up, down or 
sideways, can be sustained very long unless it has a clear impact on resource 
allocation. Given the responsibility to allocate too few funds to implement too many 
good ideas, the Faculty Computer Committee began to explore issues of academic 
priority and organizational efficiency, in other words began to plan strategically. It 
is similar resource allocation constraints which motivate presidents to initiate top- 
down planning efforts. Perhaps the logical problem of optimizing limited resources 
should be the key concern. Whether the problem is attacked by a president, top- 
down, or a faculty group, bottom-up, is less important than the logical and political 
quality of the solution. If the plan and its implementation improves the institution 
and is supported by the community then its origin is unimportant. 



8 

60 



REFERENCES 

Beltrametti, Monica. "Computing Services Planning, Downsizing, and Organization 
at the University of Alberta." CAUSE/EFFECT . Fall 1993, pp. 11-18. 

Coughlin, Patrick J. Computing Strategies in Small Universities and Colleges . 
Boulder, CO: CAUSE Publications, 1986. 

Falduto, Ellen F., Golden, Reid M., Beyer, William, Conley, Davis B. & Detweiler, 
Richard A. "Opportunistic Planning for Information Technologies: Upside-Down or 
Downside-Up?" CAUSE/EFFECT . Fall 1993, pp. 19-26. 

Moss, James, "Rensselaer Polytechnic Institute" in Campus Computing Strategies . 
John W. McCredie, Ed. Bedford, MA: Digital Press, 1983. 

Rosser, James M., Kunselman, JoAn, Penrod, James I. "California State 
University/Los Angeles," in What Presidents Need to Know about the Integration of 
Information Technologies on Campus . Boulder, CO: CAUSE Exchange Library, 
1992. 

University of Montana, Joint Information Technologies Planning Committee. 
Information Technology Plan for The University of Montana . 1992. 

Weber State University, Academic Computing Development Plan. 1991-94 . 1991. 

Weber State University, Academic Computer Plan, 1993-95 . 1993. 




THE ART AND POLITICS OF RE-ENGINEERING UNDER CRISIS CONDITIONS 

Lynn A. DeNoia 
Bryant College 
Smithf ield 
Rhode Island 



Re-engineering an entire college administration can be 
daunting — wholesale change is intimidating and 
unwelcome to many. Common wisdom from the literature 
suggests that re-engineering should take place in times 
of stability and good fortune. In practice, there may 
be little motivation short of crisis for even launching 
an encompassing re-engineering project. This paper 
describes how Bryant College got started on such a 
project, the crisis conditions under which the project 
is proceeding, and the lessons we have learned to date. 
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MIS Project Background 

In early 1991, Bryant College's administrative information system 
(IS) consisted of a set of independent modules for major 
functions, each with its own internally defined, flat data files. 
Most had come originally from a package purchased in 1986, but 
had been extensively modified. Custom linkages had been built 
between modules to copy data from one area to another. People 
were reasonably satisfied with existing functions, but requests 
for changes and enhancements were being met very slowly, or not 
at all for lower priority offices. In fact, the combined 
backlog of requests and necessary systems maintenance was 
estimated in excess of 200 days of programmer/analyst effort. 

New leadership in the Development, Alumni, and External Affairs 
Division found the available IS functions to be inadequate for a 
proposed major fund-raising campaign. Their inquiry about 
possibilities for improving existing or acquiring new systems 
provided the impetus for a College-wide review of administrative 
IS needs* The Executive Director for Information Technology 
(EDIT) asked Vice Presidents to name representatives from major 
administrative offices to an Administrative Systems Advisory 
Committee (ASAC) . The ASAC, which was first charged with 
articulating needs, became an important forum where members 
learned from each other about how the College did its business 
and how similar many of their needs were. 

The EDIT then involved ASAC in development of a Request for 
Proposal to replace the existing administrative systems with a 
comprehensive set of applications built on an underlying, 
integrated database. Pricing was requested for initial purchase 
of Alumni/Development support alone, and for acquisition of a 
complete system to handle student information and services, and 
College financial support functions as well. By the time they 
completed functional evaluation of the candidates, ASAC members 
concluded that enrollment management might benefit from a new 
system as much as, or even more than, Alumni/Development. 
Consequently, ASAC recommended acquisition of a complete new 
administrative management information system (MIS) , and the EDIT 
proposed it to senior management. The proposal was endorsed by 
the Board of Trustees in May 1992, a contract was negotiated, and 
system implementation got underway. Admission and Development, 
the two sources of College revenue, were targeted for first 
implementation . 



College Context: Crisis and Opportunity 

In addition to declining demographics, for which we had been 
planning, Bryant has also been faced with a Northeast regional 
economic slump and a significant, unexpected loss of student 
interest in undergraduate business majors, our academic 
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. specialty. Much of the motivation for the new MIS came from 
i« ' interest in acquiring better tools to support improvements for 
! i the Admission and Financial Aid Departments in marketing and 
; ' recruitment of new students, key activities in our consolidated 
I \ approlacl^ to enrollment management. We also expected to 
\' contribute to retention by improving the timeliness of, and 
enhancing services to, continuing students. 

During the fall of 1992, following budget cuts and administrative 
staff reductions, the College faced growing organizational unrest 
among its faculty and staff. While the EDIT had always intended 
for the MIS project to provide an "excuse" to foster examination 
of business processes. College economics and politics made that 
more important and more difficult at the same time. The pressure 
was on all areas of the College to cut costs, increase revenues, 
and generally do more and better with fewer people. In 
retrospect, it is easier to see that most participants did not 
appreciate the time or effort involved in shaping and learning a 
new system, much less in re-engineering our business. We 
continue to be faced with constraints on staff time and 
resources, needing to run up the learning curve and maintain 
business operations both, in offices already feeling overwhelmed 
by short staffing. 

Project Approach and Major Players 

The Executive Vice President (EVP), with primary responsibility 
for enrollment management and particular focus on recruiting, 
became the senior-level project champion. The EDIT took overall 
responsibility for project success, beginning with hiring a 
Project Manager to be responsible for the team of programmers and 
analysts. This person was selected by a search committee 
composed of two IT staff and three ASAC members who would be 
users of the new system. The EDIT also requested full-time ^ 
assignment of a Team Leader from user ranks to guide users in 
shaping the student information system. We described the roles 
of these latter three as: chief politician, chief technical 
expert, and chief user advocate. Together they formed a 
management triad for project direction and execution, picking up 
leadership for the project from the ASAC. 

Because she had chaired ASAC through that activity, the Team 
Leader easily carried forward the collaborative and educational 
advantages of ASAC's participation in the MIS selection. Her 
first task was to fill all the code tables that tell the software 
package how Bryant wants to work. She drew representatives from 
every administrative office involved with students to form a 
Coding Committee. Together they examined and agreed on values 
for over 100 system tables, while the EDIT had ASAC went on to 
formulate policy recommendations for who would have access to 
what data for what purposes. 
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Guided by the software vendor, all administrative offices 
participated in an overall project schedule planning exercise • 
Discussions of work breakdown into tasks and relative timing were 
later held by the Project Manager with individual offices. The 
schedule was then adjusted to fit work around periods of peak 
office activity. The order of implementation reflected 
expectations for benefit or internal software linkages, e.g., we 
put admissions first and the group of financial aid, accounts 
receivable, residence life, and registration second. One thing 
we failed to do, however, was incorporate the process review and 
analysis activities overtly into the project schedule — not even 
as placeholders for time or staff assignments. 



Getting Started — Admissions and Financial Aid 

With our eyes on the potential benefits of making new tools and 
capabilities available to people responsible for ninety percent 
of College revenues, we jumped into implementation of the 
admissions module for the full-time undergraduate Admission 
department. The first target date, to capture data and generate 
correspondence for prospective applicants, was missed by three 
months, primarily due to late delivery, installation, and 
debugging the setup of hardware. Beyond this, IT did not fully 
understand, until the module went into live operation, that 
Admission staff expected to get exactly the same reports (content 
and format) from the new system as came from the old one. We did 
discover that management commitment to process review was 
inconsistent across departments, however, as soon as the EDIT 
convened a group to assess alternative approaches to data entry. 
No commitment to consider or implement change was generated. At 
the time, the perspective from the Director of Admission was that 
people could not appreciate how different the new system might 
allow things to be until they had "put their hands on the 
keyboard" to gain experience. This tended to drive us to take an 
incremental, rather than a synoptic, approach. 

While software implementation activities were focused on 
undergraduate admissions, we took a different approach with 
Financial Aid. A faculty member from the Computer Information 
Systems department offered and was encouraged by the EDIT to 
begin from a process review perspective. He interviewed Fin-aid 
staff and documented their existing operational procedures, data 
flows, and decision processes, and fostered discussions about 
what improvements they would like to make in their services. 
People concluded that improvement would be more likely if changes 
crossed departmental boundaries instead of being confined within 
Financial Aid. By this time, however, pressure on IT to address 
Admission's issues was so great that no forum was provided to 
extend the Fin-aid discussions to the related departments. All 
IT support for Financial Aid became focused on adapting to the 
new federal rules under the Higher Ed reauthorization. 
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In an attempt to consolidate articulation and understanding of 
Admission's expectations, the EVP was eventually called on to 
moderate development of a '^contract" between Admission and IT 
that listed functions and reports required to make the software 
implementation "successful-" All available programming 
resources, including an outside contractor, were then assigned to 
Admission to clean up outstanding items • A new schedule was 
proposed, naming a new target for complete live operation by 
Admission and, after discussions with other departments, dropping 
the next modules back about six months. The EDIT suggested 
separating Admission, as Phase I, from the next modules, as Phase 
II, to formalize what had been learned into a different model for 
project leadership and management. 

Toward the end of the period of intensive focus on Admission, the 
EVP and EDIT agreed on a quick review by an independent 
consultant of the project status and recommended schedule and 
management changes. Interviews were arranged, recommendations 
received, and proposed changes endorsed. The consultant assisted 
us to focus and articulate what we had learned so that it could 
be captured and put to use for the remainder of the project. 



Lessons Learned 

Probably the most basic lesson we have learned is: 

(1) effective re-engineering is difficult to accomplish as 
a byproduct or side effect of another project. 

The level of commitment for time and resources must come from the 
top down and be consistent across the College. Our financial 
concerns made the dollar investment in acquiring the IS hardware 
and software paramount in most minds, focusing staff time and 
energy on opportunities for cost recovery or revenue enhancement 
rather than service or business improvements. It is critical to 
set the context and project philosophy to emphasize customer- 
service enhancement and job effectiveness, NOT the information 
technology tools. Today this seems rather obvious, but when we 
started, little practical guidance was available in the 
literature . 

The most important lesson we have learned to date is: 

(2) there is a huge difference between user participation 
and user control. 

User departments at Bryant were accustomed to asking IT for data 
or functions, having IT go away and make it happen. Previous 
system conversions had been done over a week-end and were largely 
transparent to user operations. The EDIT's inclusion of ASAC, 
not just in evaluating candidate systems, but in making the final 
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selection, can now be seen to fit a familiar pattern of user 
control, although the process was quite different. The 
departures came when control transferred to the project 
management team, and substantial user participation was required, 
first for coding and then for implementation tasks (such as 
training each other, learning the query language, documenting 
procedures, etc. — things that had been done for them by IT in 
the past). In retrospect, we had gone from one extreme to 
another, from complete user control and little participation, to 
little user control with major requirements for participation. 

We've found that an important companion to control is: 

(3) users need to be accountable to each other for system 
decisions that affect overall project implementation 
schedules . 

We really caught ourselves on this one — with IT, particularly 
the programmer/analysts, taking all the heat for missed target 
dates, when users had actually been expanding their expectations 
and functional demands as they learned more about the new 
software capabilities. The more energy IT invested in Admission, 
for example, the less time was available to prepare for the next 
set of modules. IT staff became incredibly discouraged at not 
being able to finish things on time. Admission got no nearer to 
completion, and other users began to lose interest, feeling we 
would never get to them or would not be able to meet their needs 
either . 

A lesson it has taken us some time to appreciate is: 

(4) our vendor did not understand what was involved in, or 
assume adequate responsibility for, ensuring the 
success of our project . 



Phase II — What We Plan to Do Differently 

After more than one year's work on Admission, the EVP has 
reconvened the ASAC with a longer-range charge to advise the EDIT 
on administrative technology needs, serve as a clearinghouse for 
information related to campus-wide administrative computing, and 
keep the EDIT apprised of issues. For the duration of the MIS 
implementation, a subcommittee of the ASAC, called the MIS 
Steering Committee, will be responsible for guiding the project 
by defining the scope of activities, setting priorities, and 
monitoring progress. Membership on the Steering Committee 
includes a representative from completed modules, to provide 
insight from experience, and representatives of the modules 
currently being implemented. The Committee will be chaired by 
the Dean of Administration; the IT Project Manager a nd the vendor 
account representative will provide resources. We thus return 
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control of the project to the first-line users, giving them back 
responsibility, and matching that with accountability, for 
project decisions. 

The first task for the reconvened ASAC is to review and finish 
documenting their policy recommendations for data access, 
privacy, and security. The EDIT will also ask ASAC to consider 
the questions raised by senior management about how much process 
review and design the College can "afford" right novj. Our 
impression is that only a grassroots commitment could rekindle 
enough enthusiasm to carry the re-engineering effort forward. My 
concern is that, while necessary, it may not be sufficient so 
long as a crisis attitude prevails, ' Every office needs to 
continue operating with fewer staff, making project time 
difficult to carve out of routine office duties. This is the new 
reality, however, and we must learn to cope with it better. 
Upper level management commitment for any re-engineering is 
vital; it remains to be seen whether ASAC can generate it. This 
is another, although possibly local, lesson: 

(5) it is difficult, if not inappropriate, for re- 
engineering leadership to come from IT, 

On the other hand, upper management support is clearly necessary, 
as demonstrated by the success of a process review completely 
separate from the MIS implementation, A registration process 
study group was charged by the EVP to examine the various ways 
and places we perform student registration (full-time 
undergraduate, part-time undergraduate, graduate , continuing/ 
professional) and to recommend appropriate consolidations for 
economy of operation and improvements in service. The MIS 
Project Manager was a member of the committee ^ but served only as 
a consultant on how the new MIS might support any changes under 
consideration. This group's work was incorporated into a recent 
restructuring of the Academic Affairs division, but has not been 
used to advantage as a prototype for other process review 
activities , 

For phase II then, the EDIT will try to focus IT's attention on 
serving customers with the software implementation. We need to 
capitalize on what we learned with Admission, including creating 
more formal "contracts" to specify functions and reports that 
will constitute "successful" implementation. These will be 
developed under the supervision of the MIS Steering Committee to 
ensure College objectives ahd schedules are met and that required 
resources (IT and administrative staff) are available or can be 
obtained. In addition, IT needs to pay more attention to the 
time required for users to develop a level of comfort in 
understanding the new system capabilities before certain 
decisions about the suitability of functions and operations can 
be made . 
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During phase II, IT must: 



1. Focus on the user by: placing early attention on user 
needs and expectations; finding ways to build 
credibility and forge alliances within each user 
department; paying attention to user business 
requirements and perspective • 

2. Stay grounded in reality by: pairing up visionaries 
with detailed pragmatists ensuring that planned changes 
are realistic (e.g,, in Admissions, we assisted with 
redesigning their application form so that data on the 
form matched the order of items in the new data entry 
screens) • 

3. Build user investment by: putting their hands on the 
system as soon as possible, and guiding them to see it 
as part of the solution rather than a new problem. 

4 . Find ways to bring underlying assumptions to the 
surface by: writing things down (the "contracts"), 
working beside users in their environment, and 
checking, checking, checking with those users. 

5. Keep things moving by: involving users continuously, 
building on project momentum, and especially enlisting 
and encouraging user "champions," 

6. Capitalize on user strengths by: encouraging and 
harnessing user enthusiasm and creativity, making a 
concerted effort to "see it their way," 

7. Encourage the celebration of victories by acknowledging 
the effort, investments, and progress made by all 
involved with aspects of the project. 

Meanwhile, the Steering Committee will be intimately involved 
with the detailed progress of the MIS implementation. They will 
report to ASAC at least quarterly, creating a vehicle to 
communicate that progress widely. We hope that users of modules 
still to be implemented will develop a better sense of what it 
takes to achieve, and the likelihood of, success for their areas. 
Each will serve on the Steering Committee as we move to their 
module in the implementation plan. The Steering Committee will 
also report to the fciVP quarterly so that progress can be 
communicated to the rest of senior management. We expect to use 
broader communication of objectives, responsibilities, target 
dates, and progress to focus the community on the MIS 
implementation as a College-wide, not an IT, project. 
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A Parallel Impleinentation 

One of the reasons we are disappointed with our progress on the 
student services and information side is the contrast with our 
Alumni/Development experience. This area has a much smaller, 
more tightly knit group of people (consisting of only two rather 
than twenty department/offices), who were coming from old 
software that provided separate files for alumni, donors, and 
giving history, along with some transaction processing. Little 
customization or enhancement had been done because there had not 
been consistent leadership in the division for long enough 
periods. We used a parallel project approach with a team leader 
for implementation and a user committee to specify the necessary 
code values. 

In working with Alumni/Development staff, we found that the size 
of the gap between an inadequate old system and a very 
sophisticated new one was a definite bonus. Reviewing and 
changing how they did their business became an integral part of 
discovering how to set up and use new capabilities to advantage. 
User expectations about the learning time and energy required 
were more realistic from the beginning, and there was no history 
of having IT "do it for them." The software modules require 
outside linkage only to the General Ledger; otherwise they are 
self-contained. Because this mirrors our organizational 
structure, it was easy for users to accept — they did not have 
to coordinate with formerly independent offices to make the 
system effective. Successful implementation of very 
sophisticated functions was achieved in less than one year. 

Major benefits of the process and system are quickly being 
demonstrated. Although key users left the College during the 
implementation period (the team leader and several directors), we 
have restructured and combined staff functions from previously 
distinct areas to reduce the total number of positions and still 
operate better than ever before. Our first supported phonathon 
is currently in progress. 



Conclusions ^ — While They May Seem Obvious... 

To re-engineer successfully, we now understand better that one 
must: 

1. Emphasize enhancement of customer service and 
improvements in job effectiveness — not the 
information and technology. 

2. Get users invested in designing and becoming part of 
the solutions — instead of allowing them to wallow in 
the problems. 
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3. Coach IT staff into a user-based, customer-service 
perspective — instead of allowing them to concentrate 
on installation of technology. 

4. Formalize the process of discovering assumptions, 
articulating expectations, and building shared vision - 
- instead of assuming that everyone is moving in the 
same direction toward the same goals. 

5. Create formal, public user stakes in the project. 

6. Find ways to create early successes, even if small, and 
publicize, publicize, celebrate — don't assume that 
successes are obvious or that everyone notices them. 

7. Make sure that project management is handled by a team 
with a strong, consistent vision, operating with a 
single philosophy, and communicating clearly among 
themselves and with others — not simply a group of 
people cooperating during a project term. 

8. Set goals realistic for both the people and the 
institutional setting, and try to establish metrics for 
assessing benefits to be achieved. Don't allow the 
vendor to set goals, and don't follow someone else's 
plan — it is rare for sister institutions to have 
similar enough characteristics. 

9. Have everyone who is affected by the changes 
participate — even if they argue that their 
contribution will be minor. 



10. Recognize the enormity of the effort: the time, 

energy, people, and physical resources required — 
there is no "free lunch." 



Above all, expect that re--engineering will be a complex, often 
bewildering, and typically threatening "change process" for both 
IT and users. We've found that the management key to successful 
re-engineering is to reduce the associated personal, process, a*nd 
organizational uncertainties. We should manage the risks and let 
the participants design and manage the processes. 
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Abstract 



As most higher education institutions in the country are facing budget and staffing cuts, 
administrators are looking at less staff-intensive methods to accomplish administrative tasks. This 
paper describes how the University of Delaware's Office Systems group addressed this reduction 
in staffing issue by identifying it as a new challenge for cost-effective use of Information 
Technology. The Office Systems group helps departments and colleges face the challenge of 
implementing automated systems. We guide users through a process of analysis, system design, 
integration, funding, documentation, and implementation. The approach is one of offering 
solutions rather than technology. We present our recommendations in a comprehensive package 
that also includes practical considerations such as physical office space requirements, or the 
appropriateness of the building's existing electric and telephone wiring. The Office of the Dean 
of Students project will be presented as a case study to illustrate our approach. 
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Doing More With Less: 
A Pragmatic Approach to Getting the Work Done 

The Concepts 

From information Center to Office Systems - Beyond Word Processing 

The University of Delaware is a multi-campus university system. It enrolls more than 20,000 
students and employs nearly 1,000 faculty and over 2,300 professional and salaried staff 
membersV In late 1984, the University of Delaware's MIS department established a service 
within its management structure to provide office automation for the administrative branch of the 
University. The Information Center (IC) was created to conduct needs analyses, document 
studies, and cost projections for secretarial staff office automation. A task force was established 
to select a word processing standard, and a plan was laid out to bring the affected staff up to par 
in terms of computing. Three staff and a manager were hired to start the process, and in the 
Spring of 1985, the conversion to word processing was started. 

Since then, the Information Center has continued its crusade for computer literacy of the 
University's staff by providing support for the mission-critical mainframe data as well as the many 
user-developed, microcomputer-based systems that were popping up in the administrative offices 
as a result of a mainframe system development backlog. 

Today, the IC no longer exists; instead, it has been superceded by a new support team for 
administrative computing called Office Systems (OS). The goal of this new team is to help 
administrators cope with the significant cutbacks in staff and funding that have resulted from 
budget reductions over the last four years. Our mission now reaches far beyond simple word 
processing, and our users are more knowledgeable and computer literate. 

Facing a Better Trained Workforce 

Desktop computing was introduced in 1984 when office automation began on campus for the 
administrative offices, and a University grant was established to provide the faculty and 
professional staff with an opportunity to purchase a personal computer at low cost. Nine years 
later, this investment has paid off: we now have a well-trained workforce and a good level of 
computer literacy among faculty and professionals. 

From Hand-Holding to Think-Tanking 

No longer does the Office Systems staff have to show users the benefits of word processing or 
electronic record keeping. Our users have experienced the many benefits first hand. Now they 
want more, and they create their own think-tanks within their departments to come up with new 
ways to do their daily work. The Office Systems staff helps them put their ideas into a form that 
is usable within their department without too steep a cost or learning curve. We also try to make 
the new s/stems fit into existing ones without too much redevelopment or investment in new 
software and hardware. Cost-effectiveness and staff productivity are our primary goals. 
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Are We There Yet? Planning For Solutions Yet To Come 

While we help our users with their automation goals, we also teach them how to plan for new 
solutions that the University's Computing and Network Services department is envisioning for the 
future. For example, CNS is currently in the process of wiring our campus for Ethernet. Most of 
the administrative staff have been working in an SNA environment for more than ten years, and 
are reluctant to accept the change. They are unaware of the many applications and wealth of 
information available to them via access to the Internet, it has therefore been the goal of CNS to 
provide the users with this knowledge and to make them aware of the benefits by creating real- 
life solutions otherwise not available to them. Other emerging technologies are being 
implemented on our campus such as electronic forms, kiosks, voice-mail, cable TV and digital 
technology to all dorm rooms and offices. 

Increasing Productivity Within Budget Constraints: The Ultimate Challenge 

Because of the continuing price reductions in computing equipment, it has been possible for the 
Office Systems group to increase productivity in various offices on campus while still maintaining 
the continuing level of budget reductions required by upper management. Often, this has 
presented some real challenges and required some very creative suggestions from both users and 
Office Systems staff. For example, at the time when the staff of the University Secretary was cut 
in half, a decision was made by the Board of Trustees to significantly increase the number of 
advisory committees to the Board. This resulted in a tremendous scheduling problem for the staff 
member in charge of organizing the committee and board meetings. The Office Systems staff 
provided the staff member with a turnkey system that practically runs the whole process. The 
new systems selects committee members, prints invitations, creates meeting minutes, interacts 
with food services and schedules transportation for committee members. What used to take 
several staff days to do by hand is now done in minutes by one operator. 

How Did Office Systems Know You Were Shorthanded? THEY ASKED! 

As in the Paine-Webber TV commercial, the Office Systems staff planned for the constraints 
users' offices were experiencing when faced with staff and budget cuts. We asked our users how 
they planned to cope with less staff, yet perform the same amount or more tasks with a leaner 
budget. Many offices were so short-handed that they simply hadn't even thought of how they 
would cope. Many were so backlogged that they would not even want to hear about changing 
their work habits or learning new technologies that would help them cope with their workloads. 
We helped them realize that they needed to streamline their systems and become more efficient 
in the use of their staff. We also helped them realize that by using the technologies available to 
them, they might at first see a decrease in productivity because of learning curves, but would 
soon see a tremendous gain in productivity that would allow them to structure their offices and 
task assignments in a more effective way. And we gave them our unconditional support and 
help through the learning period. 



CAU.Sf^H; Doing Morv With less - Univorsity of DcLiw^ro f'^gP- ^ 

74 



ERIC 



178 



Overcoming the Daily Routines: Leaving Room for Planning 

One of the biggest obstacles we encountered when helping our users plan for better office 
systems was the remark "I just don't have time to talk to you right now!" And they didn't! We 
could see firsthand how overworked some of these people were. In the Dean of Student's 
Office, for example, we found that we could not speak to anybody for longer than 1 minute 
before being interrupted by telephone calls. Soon we realized that most of these telephone calls 
were redirected to the Registrar's Office or to the Admissions Office. So the first suggestion we 
made was to put an answering machine on the telephone to screen these calls. IT WORKED! 
Even though they did not quite get an answering machine, they did purchase new telephones 
with features capable of rerouting calls. This interim solution was preferred while waiting for the 
campus-wide implementation of voice mail for administrative use during fiscal year 1994. 

Involving our Buddy: The CRP 

We have a network of "buddies" in place on our campus. They are our departmental contacts 
and we refer to them as the department's Computer Resource Person (CRP). The CRPs are 
trained thoroughly in computing applications and receive preferential treatment from CNS in 
terms of support. In turn, they provide CNS with a resource to funnel information for 
dissemination to the users and back to CNS. Since the CRP knows the business environment of 
the department, we work through the CRPs to find systenn^ suitable for automation. They are 
present during all meetings with the department and are the channel through which we report 
progress to the department. 

Asking the Right Questions and Getting the Right Answers 

When thinking about office automation, it is imperative that the Office Systems staff know how 
to receive correct information from the users. Asking the right questions is therefore key. We 
make a concerted effort to avoid using computer jargon and to talk business rather than 
technology. Using this approach has given us many opportunities for opening communications 
with other departments on campus and often puts two peopie together to solve issues without 
our help. For instance, when we interviewed the CRP of our College of Engineering, we learned 
that one of the secretaries rekeyed into a word processor all the recruitment information received 
from the Admissions Office about minority students. We spoke with the Admissions Office and 
asked if this information could be obtained in electronic format. The answer was "certainly." 

Is Management Support Necessary? 

Attempts to obtain management support for our automation projects have been successful in 
var>'ing degrees. We found that the degree of departmental management involvement is 
correlated to the project's successful implementation. Even though most requests come to us 
from the clerical staff, our most successful projects have been those in which we have involved 
management from the very beginning. If management is not sold on the process, the projects 
will not be successful, and a lot of time and energy will be wasted. 
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What About Funding? 



Office Systems staff do not help departments obtain funding for automation projects. We do 
suggest avenues for the department to pursue to obtain support and funding. One alternative 
may be to spread implementation cost over more than one fiscal year. Another option may 
involve requests for grant money matched with department funds. We found that once a 
department believes in the benefits of the automation project, they will find the funding for it. It 
is the duty of Office Systems to provide the department with a complete and realistic cost 
analysis for the project, and to make sure there are no financial surprises during its 
implementation. 

Don't Forget to Implement the Project: Doing It As You Go 

As ^ rule, we take care of tasks not requiring funding during the project analysis period. This 
"instant gratification" approach encourages the department to continue the project and see it 
through to completion. Once funding is obtained and the project implementation stage has been 
reached, we find that we need to make sure implementation goes smoothly and as planned. We 
monitor progress through the CRP and provide the department with our assistance if deadlines 
are not met. All too often, departments "forget" implementation deadlines when workloads peak 
periodically during the semester. While we accommodate these peaks in our project plan, we 
find that users forget to pick up where they left off after the peaks have passed. We make sure 
that they continue implementation by offering our help during these periods. 

The Process 

Background 

Before Office Systems begins working on an office automation project, we have a staff meeting 
and brainstorming session to decide how to approach the project(s). Our objective is to make 
recommendations for improving office functionality and promoting usage of the facilities and 
information available to the departments on the central mainframes. We use the following steps 
as a guide for conducting a successful needs analysis. 

Steps Involved in Accomplishing the Objectives 

Step 7: Interview all staff members. 

Before the project begins, a letter is sent to the CRP (the computer resource person within the 
department), along with a list of questions we plan to ask. The CRP is instructed to give a copy 
of the questions to each staff member. The CRP is also involved in scheduling the interviews 
and may attend each intervie^w, if desired. A sample of the questions we ask is provided in your 
handout materials. 

Step 2: Write preliminary report. 

Our findings are compiled during the next month or so, and a preliminary report is written. The 
report is returned to the CRP to verify that we made an accurate depiction of their office 
procedures. 
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Step 3: Perform walk-through with selected CNS staff. 

The walk-through is an informal meeting with members of the Computing and Network Services 
staff. During the walk-through, we review the preliminary report openly and brainstorm 
alternatives to our recommendations. Members of CNS provide information on what data is 
available on the central mainframes, and how the department can utilize it effectively. 
Connectivity issues are also discussed, if necessary. This walk-through helps assure that our 
iGcommenddtions are in line with CNS's long-term strategy. 

Step 4: Conduct interviews with departments interacting with the College or Department. 

Commonly, the department being analyzed interacts with one or more outside departments on a 
regular basis. In this step, we mee; with staff member(s) in the other departments so we can 
determine solutions that will be in ihe best interest of ail departments involved. 

Step 5: Include recommendations and cost dnalysis in the report. 

In this step, we revise the preliminary report, considering the findings from the walk-through and 
notes from the outside departments. Also, new equipment recommendations and connectivity 
needs are included. Finally, we determine the approximate cost of the project. 

Step 6; Submit final report and implementation plan to the Dean or Department Head. 

The final report is submitted for approval to the Dean or Department Head. If they agree with 
the plan, then implementation can begin. 

Step 7: Find funding sources and obtain funding. 

Most departments don't have the money readily available to fund these improvements. So, in 
these instances, we present our recommendations to the Department Head, who can use it as 
justification to request funding from their superiors or other suggested sources. Sometimes the 
Provost's office agrees to fund a portion of the project. 

Step 8: Implementation. 

This includes everything from ordering new equipment to submitting work orders for data line 
installation, to installing software and training the users. The time frame for this step is entirely 
dependent on what needs to be done. It can sometimes take over a year to complete. Finally, a 
turnover letter is sent to the department to mark the project end. 



The Case Study 

Overview 

The Dean of Students Office (DOSO) consists of four professional staff members, one non- 
professional support staff member, and two secretaries. The office provides numerous services to 
students at the University and is also responsible for handling judicial matters. When the new 
Assistant Dean of Students joined the staff in 1990, she noticed the large amount of manual 
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work that was involved in tracking a judicial referral through "due process" and thought that 
there must be an easier way to do it. She also found it difficult, if not impossible, to gather 
statistics on current cases for her regular meetings with the Judicial Council. Then after losing 
one of her support staff members, she called on the Office Systems group to take a look at how 
her office conducts business. 

Observations 

The following is a list of the major responsibilities of the Dean of Students Office: 

- Track Judicial referrals and due process 

Includes scheduling pre-hearings, hearings and related appointments, and 
preparing ad hoc reports and end-of-year statistics 

- Track off-campus tickets issued against students 

- Process student withdrawals 

- Track crisis data 

- Maintain office staff sick and vacation records 

- Answer telephones and direct calls 

We found that most of these functions are performed manually, with an over-abundance of forms 
and paperwork shuffled within the office and to other departments. The specifics of our research 
and our recommendations are described below. 

Tracking judicial referrals through the "due process" cycle is perhaps the largest and most time- 
consuming function of the Dean of Students Office. The office receives official complaints which 
are hand-recorded on a Judicial Referral Form. The referrals usually come from Public Safety 
(our university police) or Housing and Residence Life, but can be initiated by anyone. Once a 
complaint is recorded, due process begins. 

Each step of due process is tracked manually using the Judicial System Tracking Form. The office 
staff are using a database to a limited extent to record information, but an application has not 
been implemented to track the status of a case as it progresses. Approximately thirteen yearly 
statistical reports and at least one monthly report of current cases are manually prepared (hand- 
counted). 

The Office of Housing and Residence Life (HRL) works in cooperation with the Dean of Students 
Office. If a case is referred to the DOSO by Housing, it is tracked by both offices. Although the 
official file resides with DOSO, HRL keeps a photocopy of the file contents for their own 
records. If a case is referred to DOSO from another source, then Housing does not keep a 
record of it. This communication gap sometimes results in a student being issued a sanction by 
the DOSO without HRL's knowledge (behavioral history is an important consideration when 
issuing subsequent sanctions). HRL uses a simple database on their own Local Area Network to 
record rase information, but no electronic means exists for the departments to share data. 
Student files are hand-delivered daily between the two offices. 

When a student is charged with an offense by off-campus police, the DOSO is also notified. The 
DOSO retains a copy of the ticket and sends a notification letter to the student. About 200 off- 
campus tickets per semester are recorded using a WordPerfect file. However, WordPerfect's full 
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features {i.e. Sort and Search) are not utilized when reports are generated, and the data is not 
organized in any logical order. Crisis situation data is also kept in a WordPerfect document, and, 
like the off-campus charge data, reports are compiled manually and unsorted. 

Student withdrawals are also handled by the Dean of Students Office, When students want to 
withdraw from the University, they inust fill out a form at the DOSO, Then they are advised to 
personally notify Financial Aid, HRL, and some other departments of their intent to withdraw. 
An eight-part Withdrawal Notification form is then manually typed by the secretary and 
distributed to the following: the student, DOSO, Records and Registration, Accounts Receivable, 
the Academic Dean, HRL, Financial Aid, and Dining Services. A monthly list of all withdrawn 
students is prepared manually and distributed to eighteen departments. 

Miscellaneous office duties of the secretaries include answering telephones and directing calls. 
The office has eight phone lines. The phones are extremely busy, and many of the calls are 
directed to another appropriate department. One secretary is also in charge of maintaining the 
vacation and sick leave records for the staff members. These are kept on handwritten charts - 
one per employee. 

The secretaries are also responsible for scheduling pre-hearings, hearings, and appellate hearings 
with the Dean and Assistant Deans. This is all done via paper calendars. Individual calendars 
are typed up daily for the Dean and Assistant Deans. 

Each staff member has a PC with mainframe access; however, these machines are not used to 
their best capabilities. The Dean, for instance, was using an IBM Model 55sx for electronic mail 
access only, while his secretary uses an IBM Model 30 for word processing and spreadsheets. 
The oldest of their equipment was an IBM XT, which is used by the staff assistant. 

Recommendations and Justification 

We recommended the following be done to help automate the Dean of Students Office 
procedures: 

Provide each member of the Dean of Students staff with a desktop computer with LAN 
and mainframe access. 

Develop a LAN database application to track judicial referrals using R:Base 3.1, This 
includes developing an official information policy between DOSO and HRL to determine 
who has the right to access information handled by DOSO and HRL. 

Develop a means of tracking off-campus tickets and crisis data using R:Base. 

Develop an automated means of notifying the necessary departments of a student 
withdrawal. 

Purchase WordPerfect 5.1 for office staff for use with VASS (Vacation and Sick System) to 
track staff vacation and sick leave. 

Purchase R:Base 3,1 LAN 5-pack, 
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Evaluate an automated telephone answering system to direct calls. 
Provide training to the staff members. 



Since each member of the DOSO staff already had a PC with mainframe access, it was not 
necessary to make major hardware purchases. There was already a Banyan network in place in 
the DOSO's building (and HRL owns their own Banyan server), so the PCs only required token 
ring cards to connect to it. There was, of course, a connectivity charge for this. The only system 
that needed to be completely replaced was the oldest PC/XT, which was incapable of running 
the latest R:Base version efficiently. Other PC's would be swapped around the office to make 
the most of their functionality. 

We also recommended they purchase WordPerfect 5.1 and R:Base 3.1. Our campus has been 
somewhat standardized on these vendors for many years now. The Office Systems group 
developed a macro, using WordPerfect 5.1's Table feature, to track employees vacation and sick 
leave. Since the DOSO and HRL already had data in older versions of R:Base, we recommended 
they continue using that product to develop the new and improved judicial tracking database, 
which would also include the off-campus offenses. The crisis data, which was already kept in a 
WordPerfect file, could be easily imported into a separate database, also within R:Base. 

The electronic mail package that is most widely used by the administrative users on campus 
resides on our IBM mainframe and runs under TSO. This package includes a calendaring system, 
bulletin boards, conferences, and the ability to use electronic forms. Thus, two of the DOSO 
problem areas could be addressed by simply utilizing the tools already available on the 
mainframe. By granting the secretaries access to the appropriate person's e-mail account, they 
could easily schedule appointments and print daily calendars on the fly. We recommended that 
an electronic form be developed to notify the necessary departments via e-mail of a student's 
intent to withdraw from the University. 

We also recommended that an automated telephone answering system be evaluated so most calls 
could be directed without secretarial input. 

Implementation 

The first step of implementation was to obtain the necessary funding. We presented our report to 
the Dean of Students stating our findings and recommendations, as above. The Dean used our 
report as justification to ask his Vice President for the funds. His Vice President agreed. 

Once funding was acquired. Office Systems prepared the requisitions to order the hardware and 
prepared the work orders for the Data Communications group to do the wiring. Upon delivery, 
we set up the equipment, loaded software and swapped machines among users. We conducted 
one-on-one training sessions to get the users familiar with the Banyan environment. We also 
provided a custom R:Base training course for the DOSO staff members, which incorporated their 
own data into the class exercises. 

Office Systems supplied a development team to design the new judicial database system. This 
new system has been in use for about two years now. The Dean of Students staff members have 
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taken enthusiastically to it and strongly depend on it. As the staff members have become more 
familiar with R:Base, they are able to create their own ad hoc queries and reports quite 
painlessly. Office Systems provides support, along with some updates and enhancements. 

Once the judicial database was fully functional, HRL was granted access to the DOSO server to 
query the data. Although HRL has not developed their own shadow system of the data, they 
have on several occasions exercised their new query privileges. 

Office Systems also developed an automated fill-in form, which is used to notify departments and 
colleges of a student's intent to withdraw from the university. The electronic form is sent to 24 
recipients, and only one hardcopy record is maintained in the DOSO files. This new procedure 
has drastically reduced the paper flow between offices, and each office is responsible for keeping 
its own records of withdrawals. 

After some preliminary research, our recommendation for an automated telephone answering 
system was ruled out because of its extensive cost. As an alternative, new phone sets were 
installed in the office which offered more features than a standard push-button phone. We are 
awaiting implementation of a voice-mail system, which the University plans on making available 
to staff and departments sometime this fiscal year. 

Conclusion 

The Dean of Students Office is only one of the several projects that has been successfully 
implemented by the Office Systems group during the past two years. Other departments served 
are the College of Physical Education, the College of Education and the Department of Music. 
As the news of our successes spreads across campus, we have been approached by more users 
who require automated solutions for both big and small projects. 
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